Microsoft's flagship browser and Firefox 2 don't necessarily fail at HTML5... they simply fail at handling unrecognised doctypes altogether. How and why.
A.E.Veltstra
Sunday, April 13, 2008
Just to see whether I could make sense of the HTML5 specification-in-progress, I decided to create HTML5-versions of several of the pages in my website, including its homepage. Conclusion: it's feasible, but I'm sure less experienced web authors could use a "Web Authors' Guide to HTML5" (yup, this counts as prior art).
I proceeded to testing how web browsers by various manufacturors displayed that HTML5-page. The results:
Haven't tried it in MSIE8 yet... I'm part of the feedback program but I didn't want to risk having that beta application wreaking havoc on my system.
Now what's interesting about that list?
Wait, what? Opera 9.27? Does it know HTML5? It may have some basic understanding but I doubt Opera implemented the entire spec... if only because the spec is being developed as we speak. So how can it pass this test?
And how is it that Firefox 2 and Microsoft's excuse for a browser fail?
My best guess: it's because of the way browsers handle unknown elements. Huh? Point in case: HTML5 has a SECTION element. With it, an author can divide just about any part of the body in, you guessed it, sections.
How should such a section be rendered? Should it be a block? A table row? A floating square? The specification doesn't say... it leaves that directive to CSS.
So what should a browser do, when running into an element it doesn't recognise? It could simply ignore the element... but none of the current major browsers chose that option. Bravely, they try their best at displaying it anyway.
With one major difference: where some browsers (Opera 9, Safari 3, Firefox 3) display the unknown element and apply CSS and javascript rules to that element as provided by the author, some others (Internet Explorer 7, Firefox 2) display the unknown element bare, meaning without CSS and / or without javascript.
Why? Is it a strategic management decision? Is it developer short-sightedness? Is it a technical difficulty? And if so, in what part of the browser? In the HTML-parser, or in the CSS-parser, or in the javascript parser? In all 3? Somewhere else?
It can't be a technical difficulty. After all, all of the tested browsers can handle XML and do render CSS on XML documents... and XML by definition is riddled with unknown elements.
It shouldn't be a CSS-parser problem, as the CSS that I wrote isn't all that difficult and does work when applied to known elements.
It shouldn't be an HTML-parser problem, as all of the tested browsers are well-adept at handling TAG SOUP, especially Internet Explorer (yay, history!).
So that leaves...
that leaves a browser trying to render TAG SOUP using standards-compliant render-mode for a doctype that has no DTD where one is expected. It is one thing to have NO doctype, as is the case with many XML documents. It is quite another, to have a document that claims to have a doctype and then breaks the rules by providing neither a public nor a system identifier... which is normal for HTML5, but not for HTML4 nor the XHTMLs.
So unless a browser is instructed to handle such cases, it will behave in unexpected ways. If anything, the fact that both Internet Explorer 7 and Firefox 2 do display the unknown elements shows that the developers did expect some unexpected authoring and made sure their browsers wouldn't crash, which is quite commendable.
That makes the fail largely a strategic management decision.
Conclusion: Microsoft's flagship browser and Firefox 2 don't necessarily fail at HTML5... they simply fail at handling unrecognised doctypes altogether.
I proceeded to testing how web browsers by various manufacturors displayed that HTML5-page. The results:
- Opera 9.27: pass
- Safari 3.1: pass
- Firefox 3 (latest nightly build): pass
- Firefox 2: fail
- Internet Explorer 7: fail
Haven't tried it in MSIE8 yet... I'm part of the feedback program but I didn't want to risk having that beta application wreaking havoc on my system.
Now what's interesting about that list?
Wait, what? Opera 9.27? Does it know HTML5? It may have some basic understanding but I doubt Opera implemented the entire spec... if only because the spec is being developed as we speak. So how can it pass this test?
And how is it that Firefox 2 and Microsoft's excuse for a browser fail?
My best guess: it's because of the way browsers handle unknown elements. Huh? Point in case: HTML5 has a SECTION element. With it, an author can divide just about any part of the body in, you guessed it, sections.
How should such a section be rendered? Should it be a block? A table row? A floating square? The specification doesn't say... it leaves that directive to CSS.
So what should a browser do, when running into an element it doesn't recognise? It could simply ignore the element... but none of the current major browsers chose that option. Bravely, they try their best at displaying it anyway.
With one major difference: where some browsers (Opera 9, Safari 3, Firefox 3) display the unknown element and apply CSS and javascript rules to that element as provided by the author, some others (Internet Explorer 7, Firefox 2) display the unknown element bare, meaning without CSS and / or without javascript.
Why? Is it a strategic management decision? Is it developer short-sightedness? Is it a technical difficulty? And if so, in what part of the browser? In the HTML-parser, or in the CSS-parser, or in the javascript parser? In all 3? Somewhere else?
It can't be a technical difficulty. After all, all of the tested browsers can handle XML and do render CSS on XML documents... and XML by definition is riddled with unknown elements.
It shouldn't be a CSS-parser problem, as the CSS that I wrote isn't all that difficult and does work when applied to known elements.
It shouldn't be an HTML-parser problem, as all of the tested browsers are well-adept at handling TAG SOUP, especially Internet Explorer (yay, history!).
So that leaves...
that leaves a browser trying to render TAG SOUP using standards-compliant render-mode for a doctype that has no DTD where one is expected. It is one thing to have NO doctype, as is the case with many XML documents. It is quite another, to have a document that claims to have a doctype and then breaks the rules by providing neither a public nor a system identifier... which is normal for HTML5, but not for HTML4 nor the XHTMLs.
So unless a browser is instructed to handle such cases, it will behave in unexpected ways. If anything, the fact that both Internet Explorer 7 and Firefox 2 do display the unknown elements shows that the developers did expect some unexpected authoring and made sure their browsers wouldn't crash, which is quite commendable.
That makes the fail largely a strategic management decision.
Conclusion: Microsoft's flagship browser and Firefox 2 don't necessarily fail at HTML5... they simply fail at handling unrecognised doctypes altogether.
Need problem solving?
Talk to me. Let's meet for coffee or over lunch. Mail me at “omegajunior at protonmail dot com”.