Friendly browsers
Tags: browser, web, webdev, html
Published: 2019-03-27 13:03:29

---
title: Friendly browsers
published: true
description: Browsers forgive developers mistakes
tags: browser, web, webdev, html
cover_image: https://thepracticaldev.s3.amazonaws.com/i/iadk9u3rioiqiejo0p11.png
---

This is a small post about how browsers help us web developers. It will not contain any in-depth information but more a general approach. Maybe in a future blog post I will go into details. Also this post will be focussed on HTML errors.

_Even with the powerful IDE's that we have with build-in linting and warning messages, with all the external linting checks that can be triggered by pre-commit hooks, Github commit triggers, ... endless options that we devs have but we still make mistakes._

The types of errors that I am referring to are also in the DEV project, I think most of them have now been fixed over the past couple of weeks.

{% github https://github.com/thepracticaldev/dev.to/issues/1828#issuecomment-465199995 %}

**These are very small errors that are easily overlooked but still they are valid errors that should get fixed.**

So even if these errors slipped through the development process, get approved by reviewers and maybe even get past linting tools (that might have not been configured correctly) the browser will in most cases still parse it correctly.
It will add missing tags in places that it thinks that they should be added, but the catch here is that this might be different for each browser so it could cause unwanted behaviour.

A very small example. I made a JSFiddle with 2 input fields, one surrounding with a div container and the other with only an opening div. The result is parsed correctly and the user will see 2 input fields.

{% jsfiddle https://jsfiddle.net/bhondtaw/1 html,result %}

Inspecting the parsed source code in my browser this revealed the second div to have parsed a bit strangely.

```html
<div>
  <input id="test" placeholder="unclosed div">

  
  <script>
    // tell the embed parent frame the height of the content
    if (window.parent && window.parent.parent){
      window.parent.parent.postMessage(["resultsFrame", {
        height: document.body.getBoundingClientRect().height,
        slug: "bhondtaw"
      }], "*")
    }

    // always overwrite window.name, in case users try to set it manually
    window.name = "result"
  </script>


</div>
```

It added the closing div tag after the script tag (added by JSFiddle), while if you closed the div correctly the script tag would be added after the div container.
_I am using Brave browser on macOS so this might be different for you depending on the browser you use. Here is an example from stack overflow that gave different results in different browsers: [CSS, HTML Web Browser invalid markup tolerances](https://stackoverflow.com/questions/4254216/css-html-web-browser-invalid-markup-tolerances)_

In my example it doesn't do any harm but depending on the browser to "fix" your mistakes might not work in all cases.

**There is actually a term for structurally incorrect HTML code: [tag soup](https://en.wikipedia.org/wiki/Tag_soup).**

I think we as developers need to keep a certain level of quality, don't be afraid to spend time reviewing your code. This is not time wasted imo, we cannot predict how the code will behave in each browser and should avoid having the browser needing to correct our mistakes. 
Having to debug this later might cost you a lot more time finding out what is going wrong, especially if you don't know what browser (and browser version) the client is using.

Like I said at the beginning there are lots of tools that help us developers with this task so please use them. For example I use the Jetbrains build in linting and warnings that alarm me about most of these issues, this is also how I found the errors in the DEV project.

But there are lots of other tools that can help you.

- Browser extensions
- [The W3C Markup Validation Service](https://validator.w3.org)
- Linting packages run by build tools

**So to make a conclusion, do not rely on the browsers error tolerance and spend time reviewing your code.**

Some other interesting links not mentioned in the post:

- [How browsers work](http://taligarsiel.com/Projects/howbrowserswork1.htm), it has a section about the [HTML Parser](http://taligarsiel.com/Projects/howbrowserswork1.htm#HTML_Parser)
- [“Forgiving” Browsers Considered Harmful](https://alistapart.com/article/forgiving)