XUL vs SilverLight | Main | Quick Note to Extension Developers About browser.xul ID Changes

January 22, 2008

What's Up, Doctype?

Not Frickin Again!

I remember the fun problems IBM ran into with doctypes (See the MDC article) - IBM created it's own doctype and put it on tons of webpages out there. Of course, IE/Netscape 4 didn't care about it and went ahead rendering in their quirky old-school way. Then Mozilla came along, and suddenly the pages no longer rendered "correctly", as the doctype (correctly) trigged standards mode. Long story short, Gecko special-cased that doctype to trigger quirks mode. Which is ugly.

Internet Explorer 7 learned a similar lesson - most web authors have no clue what doctypes really do. So IE7 broke pages that worked fine in IE6 because those pages had a doctype that IE6 ignored and paid for trying to be more compliant. But not compliant enough, because IE8 is going to break even more!

Personally, I thought IE's marketshare and the early betas of IE7 would have given people plenty of time to test and fix. But I forgot that most authors are lazy and wait for issues to arise before reacting, even though the web was full of discussion prior to IE7's release.

So now IE8 is going to introduce a new way (using meta tags) to force a page into IE8 strict mode. So now IE8 will render content in 3 different ways (IE6/IE7/IE8 mode). This means that when everyone finally gets off IE6 to a new, standards compliant IE, they will still be viewing pages using the IE6 mode.

JavaScript Toolkits will have to now figure out how to distinguish this new mode from IE7 mode and act accordingly.

And since IE8 still does IE6 mode, most web applications will probably not bother updating their code to work with IE8's changes and continue to use the IE6 mode even when no one actually runs IE6. Why should someone spend money to update the app to use the new IE changes when they can run the old code just fine. And use Silverlight for more advanced things, of course.

The question is, how long will this cycle continue? Web standards are supposed to avoid this exact issue, damn it.

Posted by doron at January 22, 2008 8:00 PM

Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference What's Up, Doctype?:

Generic finasteride. from Propecia finasteride precautions amp side effects.
Finasteride propecia. Side effects of propecia finasteride mg. Finasteride. Propecia finasteride. Propecia side effects finasteride. [Read More]

Tracked on May 2, 2009 2:36 AM

Free granny galleries. from Granny fucking.
Granny post. Old nasty amateur granny. [Read More]

Tracked on July 12, 2009 2:34 PM

Car insurance. from Car insurance for woman.
Car insurance questions. Car insurance for teens. Car insurance. [Read More]

Tracked on July 19, 2009 5:31 PM


IE8 does IE6 mode? That's an interesting point. In effect all browsers, even Firefox, will do an average job with shit code, that's what Quirks mode is for. Is anyone seriously considering removing Quirks mode? I've not read anything to that effect.

Those who don't want to update will just have to tolerate Quirks mode rendering.

I can see a future where standards mode in IE9 will be ACID2 compliant and invoked with an HTML5 DOCTYPE. IE9 Quirks mode could render like IE6 Quirks mode for all I care.

Perhaps that is the answer for Microsoft - freeze Quirks mode at IE6 Quirks level, then standards mode for everyone else.

Perhaps all the complaints MS have received about IE7's standards mode are merely because it was a half-arsed effort at standards support? Perhaps people have essentially been telling MS that they want standards, they tried them with IE7 and IE7 butchered them up? Well duh, that's because IE7 was/is only marginally more standards compliant than IE6.

Posted by: pd at January 23, 2008 9:36 PM

>> Is anyone seriously considering removing Quirks mode? I've not read anything to that effect.

No. Quirks mode will still be there. For those keeping score, IE8 will have the following modes:

1. IE6 broken mode - AKA Quirks mode.
2. IE6/IE7 "standards" mode - AKA Use-Standards-Terms-But-Render-As-You-Please mode.
3. IE8 strict mode - AKA I'm-Really-Absopositutely-Sure-I-Want-It-Rendered-Properly mode.

The problem here is that IE6 (and IE7 to an extent) made a point of actually reading and interpreting the DOCTYPE of a document, but then for various reasons, failed to follow the standards as defined in the specified type. The result was that a lot of authors (who ostensibly test their pages only in IE) created a large amount of sites with valid standard DOCTYPES, but which rendered in a non-standard way.

Microsoft's issue now, as they point out, is that even if IE8 adhered perfectly and strictly to W3C standards, all those pre-IE8 pages will suddenly start rendering strangely.

This is understandable and expected, yet Microsoft wants to avoid the bad press this will pressumably bring. Therefore, their proposed solution is not to break backwards compatibility with the accordedly broken layout engines and badly formed documents, but to add a new case to the engine: Work the same as IE7, with Quirks and Bad-Standards modes, by default (misinterpreting DOCTYPE's); and then render strictly and adhere to the DOCTYPE properly if documents contain a new attribute flagging them as requiring so.

The result will be a jump back in time to the era of "This page best viewed with X" icons. And the web will still be full of broken documents which just happen to "look right" in IE.


Posted by: DZ-Jay at January 28, 2008 10:15 AM

Micosoft doesn't want to work with standarts.
IE development stopped afer IE6. IE7 dev. began when MS fear from growing-up Firefox.

Posted by: Arik at February 1, 2008 6:01 AM

Post a comment

Remember Me?