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.

Comment for #1828

Glennmen commented on Feb 19, 2019

I already planned to make an issue about something else I found before this issue but since it is kinda related I will add it to the discussion here (if wanted I could still make a separate issue). This was something that wasn't being catched by the pre-commit linting, travis, codeclimate, ... but I only noticed it because of my IDE (RubyMine/JetBrains). None of the users probably noticed because luckily browsers are very "forgiving' and are able to parse the HTML even with errors.

Besides the linting errors that are being thrown now there are tons of HTML errors in loads of view files, some examples: Different opening and closing tags: https://github.com/thepracticaldev/dev.to/blob/e676d9fc42cb6acdb3476abc4b7074cda676edaf/app/views/pages/_publishing_from_rss_guide_text.html.erb#L6

No <dl> closing tag (multiple times in the same file): https://github.com/thepracticaldev/dev.to/blob/e676d9fc42cb6acdb3476abc4b7074cda676edaf/app/views/pages/_editor_guide_text.html.erb#L173-L178

No <h4> closing tag: https://github.com/thepracticaldev/dev.to/blob/e676d9fc42cb6acdb3476abc4b7074cda676edaf/app/views/pages/generator.html.erb#L42

I think you get the picture 😉 I would like to go through the files in /app/view/* and fix any HTML errors (and linting errors while I'm at it). But need to know a couple of things first:

• How to submit?
  • 1 Big PR
  • Separate PR's for each folder (combined by first subfolder, nested folders included in that PR)
• Linting errors that I can't fix?
  • Ignore them
  • Notify someone from DEV? to change lint rules and merge master to my branch to commit without errors.

Currently these are the only questions that I can think of.

So what you guys think?

View on GitHub

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.

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

<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

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.

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
• 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, it has a section about the HTML Parser
• “Forgiving” Browsers Considered Harmful