Why HTML 5 Specification Matters?

Author(s) and publish date

Skip to 44 comments

This is a simple story. The story of an HTML bug. Like every stories, it could start with… Once upon a time, there was a bug.

The bug and its consequences

A known HTML page contains a similar piece of code:

<div style="display:none">

The HTML code is invalid. It means that a browser which "reads" this page has to recover the errors and recreate something logical to simply display it to the user in the best case, to apply javascript and CSS code in the worst case. The browser implementer is then facing a question. How do I recreate the structure of the content? How do I catch the error and make it something usable?

Some browsers will find a recovery strategy, but not necessary the same. Some browsers will fail on the page. It means in the end two things.

  • Users with unpredictable results, then usability problems and erosion of trust.
  • Interoperability issues for browser implementers, and then a risk of losing market share (It is working with browser A and not browser B.)

How to repair?

HTML 4.01 specification is not that much help in this case. It doesn't define a precise error recovery mechanism for invalid documents. So the browser implementer has to create its own strategy with the consequences we have just talked about.

HTML 5.0 Editor's draft defines a very precise mechanism for recovering invalid markup. As we can see in the comment about the bug, Dave Hyatt says: Easy, the html5 spec covers this.

The browser implementer had clear instructions for this type, was able to implement it, and then to create an interoperable recovery system for this type of mistake. The Web users finally were able to access the Web site without troubles and in the same way than with other browsers. HTML 5 Specification matters because it creates more interoperability when recovering from errors.

Related RSS feed

Comments (44)

Comments for this post are closed.