WTF were they smoking over at the CSS 2 working group, anyway?
I wish I were more than half kidding, but every time I consider what the recommendations for DOCTYPE are going to be for application authors using Dojo, I wince a bit and mutter something vaguely obscene about crack-smoking monkeys.
The problem oddly enough starts out with good news: browser manufacturers have finally (largely) been cowed into implementing the most broadly useful portions of the W3C’s CSS 2 spec. For the most part, there is much rejoycing.
For the most part.
Once upon a time (as I was graduating from high school), the W3C CSS working group published the CSS 2 box model, which the WinIE team blithely ignored. Whatever the reason, the fact that MSIE calculated boxes one way while better browsers followed the spec to the letter caused web developers no end of sleepless nights. The answer seeemd easy: just get Microsoft to change their errant ways, and then the problem would be solved for good!
What no one bothered to mention at the time was that the box model that MSIE had been implementing was vastly simpler to use, required less head-tiling and forhead-to-desk banging. It was, in a word, better. But instead of pushing to get the spec changed, the web standards community pushed to get the browsers changed, and mostly succeeded. The mountain had been moved, but the new location wasn’t much better than the old one. IE 6.0 (PC) finally included an implementation of the W3C box model, but in Microsoft’s infinite wisdom, decided that the way to enable it would be for a page author to declare that their document in all other ways adhered to W3C standards by sending a “standards mode” DOCTYPE. This would be all well and good had things continued to improve in the specs and the browsers, but it wasn’t to be. With the release of IE 6.0 for the PC, Microsoft had killed off the competition and considered the world safe once again for onerous licensing fees on bug-ridden dekstop software. The IE team was disbanded.
Meanwhile, the W3C stopped doing anything useful too. Distractions like XForms, XHTML 2.0, and other “wouldn’t it be great if we could make web developers disappear!?” specifications creaked slowly out of an organization that lived on like so many figurehead monarchs in european democracies. And life might have been OK in this state as well, had XHTML not turned out ot be incredibly useful. You see, it’s not that humans shouldn’t be involved in designing and wiring together the bits and peices of web UIs, it’s just that users in the next “generation” of the web have turned out to be the most important source of content, which means that the tools they use need to be more automated. XML had finally found a calling for which it wasn’t a solution in search of a problem. Systems that process XML in arbitrary dialects can transform them to XHTML with XSLT or other processors and automatically generate web content from input formats that users are better accustomed to. Better yet, XML turns out to be a great way to aggregate and re-disseminate that content, and XHTML is the most straightforward resulting format since the same tools can be reused to generate and manipulate both the source and the destination formats. So where’s the problem?
Sadly, MSIE 6.0 treats well-formed XHTML documents as “strict mode” documents without exception, thereby imposing the broken W3C box model without providing an escape hatch. In the interem 4 years, the CSS working group has recognized their blunder and proposed a fix which every other browser manufacturer implemented faster than you can say “oh thank Hyatt!”. But we’re not in the clear yet. Thanks to IE’s “all or nothing” standards compliance approach, DHTML toolkits like Dojo are left high and dry. We can either recommend to end users that they build widgets which do not rely heavily on claculated formatting (a non-starter), “fake it” on IE and suffer severly degraded performance (the norm), “snif” browser on the server side and send a “quirks mode” DTD to IE, or simply serve up HTML 4.0 content to everyone and employ “border-box” sizing on the browsers that provide the explicit switch to do so. Nary a good choice in the bunch.
As a result, we’re going to be recommending the use of a broken DTD for pages serving up the stock Dojo widgets, and I don’t envisage a future that doesn’t include this kind of outright hackery (at least not in the next half decade). IE 7 is the punchline to a running joke, and it’s not even into Beta yet, meanwhile IE 6.0 controls 90+% of the browser market. The only thing that’s going to change that is Microsoft’s draconian licensing and time. Lots of time.
At least CPUs will keep getting faster so our IE 6.0 box-model contortions might run acceptably fast by 2008. I hope.