HTML5 and invalid documents - the great misunderstanding
Wednesday, 19. November 2008, 01:05:03
People keep complaining about HTML5's error handling. It looks like a lot of people believe that because the standard includes error handling, all content will be considered valid.
This statement is wrong and repeating it doesn't make it true. Yet even Sir Tim Berners-Lee himself seems to express a concern that HTML5 represents
This is probably the greatest misunderstanding about HTML5. Let's get this straight..
On the contrary, I believe that the level of detail in HTML5's error handling will make browsers and validators report more useful error messages. This will make it easier to write valid HTML.
Look at the spec. Right now I find 178 instances of the expression "parse error" in the spec text. These parse errors are validity errors that validators will and browsers may report to the user. (The spec can't dictate browsers to do so because it's a UI decision how to do it, but I'm fairly sure that Firefox, Safari and Opera will all use their existing error consoles / web developer tools to show HTML5 parse errors. After all, these errors should be so useful it would be a competitive drawback for a developer tool not to show them).
Having web browsers and validators report the same errors will help authors understand HTML and well-formedness. Today, authors who try to use the validator are baffled when the validator says a document has lots of problems, yet it works fine in browsers and they don't complain about errors. This confuses authors and makes them distrust or ignore the validator warnings.
Tomorrow, HTML5-compliant validators and browsers will report the same errors, and HTML authors will be less confused and more enlightened as a result. Hence, specifying error handling with the detail the HTML5 spec is doing should in fact contribute to improving the quality of the markup out there on the web.
This statement is wrong and repeating it doesn't make it true. Yet even Sir Tim Berners-Lee himself seems to express a concern that HTML5 represents
changes of philosophy about improving the web as opposed to letting it fester while describing it.
This is probably the greatest misunderstanding about HTML5. Let's get this straight..
- Understanding error handling is an absolute requirement for improving HTML and the Web while being compatible with current content.
- Invalid documents are still invalid.
- HTML5 browsers will not "gloss over" invalidity any more than the current HTML4 browsers already do.
On the contrary, I believe that the level of detail in HTML5's error handling will make browsers and validators report more useful error messages. This will make it easier to write valid HTML.
Look at the spec. Right now I find 178 instances of the expression "parse error" in the spec text. These parse errors are validity errors that validators will and browsers may report to the user. (The spec can't dictate browsers to do so because it's a UI decision how to do it, but I'm fairly sure that Firefox, Safari and Opera will all use their existing error consoles / web developer tools to show HTML5 parse errors. After all, these errors should be so useful it would be a competitive drawback for a developer tool not to show them).
Having web browsers and validators report the same errors will help authors understand HTML and well-formedness. Today, authors who try to use the validator are baffled when the validator says a document has lots of problems, yet it works fine in browsers and they don't complain about errors. This confuses authors and makes them distrust or ignore the validator warnings.
Tomorrow, HTML5-compliant validators and browsers will report the same errors, and HTML authors will be less confused and more enlightened as a result. Hence, specifying error handling with the detail the HTML5 spec is doing should in fact contribute to improving the quality of the markup out there on the web.
WIDGETIZE