This is a very old article. It has been imported from older blogging software, and the formatting, images, etc may have been lost. Some links may be broken. Some of the information may no longer be correct. Opinions expressed in this article may no longer be held.
So Microsoft, in conjunction with some of the folk at WaSP, has announced its intention to include the quirks mode that beats all quirks modes in the forthcoming Internet Explorer 8 in an article on A List Apart: Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8.
This has proved to be quite a controversial idea. It was not long before WaSP issued a release hinting that many WaSP members do not support the idea. Speaking in favour of the scheme we have:
In Defense of Version Targeting by Jeffery Zeldman
From Switches to Targets: A Standardista’s Journey by Eric Meyer
And against, we have:
Mistakes, Sadness, Regret by Ian Hickson (Google)
==== by Robert O’Callahan (Mozilla)
The Internet Explorer Lock-in by Anne van Kesteren (Opera)
Versioning, Compatibility and Standards by Maciej Stachowiak (WebKit / Safari)
Quotes by Dean Edwards
X-No-Thanks by James Bennett
Meta Madness by John Resig (jQuery)
And roughly neutral:
Broken by Jeremy Keith
War within Web Standards: Pragmatists vs Purists by Jeff Croft
(Interesting affiliations are shown in parentheses, but these people’s personal blogs may not reflect their employers’ views.)
I can see the attraction of such an idea from a practical point of view. Once you’ve produced a web page, you need never touch it again. Whatever changes new browser versions bring can simply be ignored — your page will continue to work.
But the realist in me makes me sceptical of that idea — will future versions really guarantee to render the page exactly the same? It seems simple enough: bundle historic rendering engines and have the browser switch rendering engines depending on the contents of a element, but on careful consideration this presents several problems:
Successive versions of the browser will become increasingly bloated, taking up more disk space and using more memory.
Rendering engines are often a source of security issues. The more rendering engines you include, logically the more security issues are likely to arise.
Fixing a security issue will necessarily involve tinkering with a historic rendering engine. It is possible that you’ll introduce incompatibilities accidentally, or you’ll be required to deliberately introduce an incompatibility to solve the security problem.
In a site using frames, potentially each frame will be rendered by a different engine. Javascript on framed pages can potentially communicate and manipulate each others’ DOMs via Javascript.
In terms of the browser “ecosystem” it’s bad news too. Non-Microsoft browser makes often feel compelled to emulate particular quirks of Internet Explorer. If they have to emulate several different rendering engines, it may slow down development significantly. It may also harm take-up of future versions of Internet Explorer — after all, why would someone want to upgrade if they will not see any improvements on 99% of the pages they visit, because they’re not using IE=edge.
The last issue is simply the vast quantities of annoying cruft that Microsoft foists upon web developers who just want to switch off their “features” — to get back to the status quo.
The Tao
Other browser makers should respond to this by phasing out quirks mode and always using their highest quality rendering mode. After all, what’s quirks mode for apart from offering compatibility with IE 5, which is dead and buried in 2008.
