HTML5: Microsoft and the opt-in catch
All was nice until the question arose whether the specification should have a version number or not. Note that WA1.0 does not specify a version in it's proposed syntax; in fact it proposes this very simple doctype declaration: <!DOCTYPE HTML> (finally one that can be remembered) and the only reason they are proposing a doctype at all is because it is needed to put current browsers into standards compliant rendering mode.
Chris Wilson soon expressed his disapproval on this design principle. It wasn't clear at that time which hat he was wearing, but that would soon become clear. David Baron on the other hand made a very good point why versioning is a bad idea. In fact, sofar HTML has actually never really needed a version number: current browsers are able to parse and render any version of HTML without having to know which version of the specification was actually used when the document was authored. If and when browsers start to adjust their rendering based on some version identifier in for instance the doctype declaration this will lead to some serious problems, especially when a leading implementation starts to do this. It is still an unfortunate fact that people need to author to specific implementations of a specification instead of adhering to the specification itself working around bugs and shortcomings in those implementations. It isn't hard to imagine that some of those people will author specifically to the leading implementation which eventually means that this implementation has to 'freeze' it's status (bugs and all) at a certain point in order to prevent those documents from breaking. That last thing is a problem for Microsoft.
Apparently Microsoft has had to swallow some nasty red pills after releasing IE7: even though they had been careful enough to target all changes and fixes that affected rendering to documents in 'standards compliant mode' (documents with a full and valid doctype) a lot of pages broke and needed fixing. In itself this is a good thing because obviously those pages were broken to begin with - at least in all other browsers except IE - but it also affected for instance intranet applications that were specifically authored to work only in IE. Now still that is definately the authors' fault - they opted in on standards compliant mode by using a full and valid doctype - but on the other hand maybe the author did not foresee the implications of using a doctype or maybe didn't even think about it and the doctype was automatically added by his authoring tool. I'd say that's the price you pay for not actively improving your product for over 5 years: people tend to start relying on certain behaviour.
So Microsoft doesn't want to 'break the web' (or at least the part of the web that is specifically catered to IE) anymore and says it wants versioning so they can 'lock down' their rendering for a specific version. Since IE is still the leading implementation out there this will eventually lead to serious interoperability problems since other browser-vendors will be forced to implement those rendermodes as well, reverse-engineering IE's behaviour and adding to the complexity of renderengines.
But then that's not all! This approach will require for regular version-updates to the specification, else there will be no new version number that can be used for authors to opt-in into improved behaviour of a new IE version. That's why Chris Wilson is arguing for another type of opt-in for improved standards compliance behaviour in IE, and already made it clear that when such method will not be defined in the specification itself they will add their own proprietary method for that - possibly some comment style based switch like the conditional comments. This will mean that IE will default to the 'old' (say IE7) behaviour unless authors explicitly define this switch in their documents.
I strongly oppose to this line of thinking and think it will both hurt the future of HTML and standards compliance as a whole for a number of reasons:
- It will make interoperability for other browser-vendors even harder when MS is 'locking down' behaviour on the same specification between IE-versions. Basically it means that in order to be fully interoperable vendors need to implement this switch as well.
- Authors will need to be aware of this switch, else they will just continue to cater to IE's bugs and rendering in other UA's will still be dependent on if and how well they reverse-engineered IE's behaviour.
- When the switch is proprietary it is even less likely authors will know about it when they just read the specification - if they read it at all. Also it will mean that authoring tools will have to implement this proprietary feature.
- Instructions that define behaviour should not be embedded in syntax that is likely to be stripped by pre-processing tools (such as comments).
- When this type of switch is specced it will eventually not lead to a uniform markup-language but will be a free ticket for implementors to do as they wish and implement only parts of the specification or define different behaviour.
- Authors need to 'opt-in' for every new release of IE meaning they will have to update all of their documents for every release of IE unless IE also provides an option to 'opt-in for now and all times'.
- This 'switch' is not a temporary solution but will become a permanent feat.
- Use the <!DOCTYPE HTML> DTD as an explicit opt-in to 'really really standards compliant mode, for now and all times'.
- For the DTD-less XML-serialized version (as a successor of XHTML): IE hasn't implemented support for this at all, so also treat this is as 'really really standards compliant mode, for now and all times'.
- Make sure you get your implementation as good as possible on the first release. Yes, that probably means a complete rewrite of Trident, but my hopes are that that's already ongoing...
- Update regularly and fix implementation bugs, an 18-month release cycle is unacceptably long - people will start to rely on your bugs in that timeframe.
- Evangelize and stop promoting your proprietary methods over standards-based ones.
- Especially for intranet-applications that rely on IE7: make sure that IE.next can be installed alongside IE7.
- And if you still think it is necessary: specify an opt-out switch.
Comments are closed