Working together for standards The Web Standards Project

When IE7 came out, sites broke. Folks throughout the web community posited many reasons why, but none mentioned the fact that all standards-enabled rendering engines are triggered by an assumption we affectionately call the “DOCTYPE switch.” I’ll truck out a dusty old cliché here: “when you assume, you make an ass out of you and me.”

So what does that have to do with the DOCTYPE switch? Well, the DOCTYPE switch assumes that if you are using a valid DOCTYPE for a “modern” language (e.g. HTML 4), you know what you’re doing and want the browser to render in standards mode.

That assumption could have worked out all right, had it not been for authoring tool makers who—with the best intentions and under pressure from us (the web standards community and WaSP, in particular)—decided to include valid DOCTYPEs in new documents by default, thereby crippling the DOCTYPE switch because it wasn’t an explicit opt-in. Now add to that the fact that IE6 had the lion’s share of the browser market for so long—thereby becoming the primary browser in which many developers tested their work—and you have a recipe for disaster: developers assumed (there’s that word again) the layout they were getting in IE6 was accurate, not realizing they had been opted-in to accept rendering engine upgrades as the browser evolved (all of which was reinforced by the 5 years of stasis in terms of IE6′s rendering).

So along comes IE7 with it’s tuned-up rendering engine and, well, it caused sites to broke.

Not wanting to see that happen again, Microsoft approached us (WaSP) to help them find a better way of enabling standards support through an explicit opt-in. You can read more about the thought process we went through in my article on A List Apart. The issue also features a commentary piece by WaSP alum Eric Meyer (who was not involved in the development of the solution, but was asked for feedback on our work) that takes you on the mental journey he took in reaction to our recommendation. The series for ALA—on what we are calling “browser version targeting”—will wrap in two weeks with a piece by Peter Paul Koch—who, like me, was involved in the development of this technique—that will cover application of the browser targeting mechanism in IE8 and beyond.

This buzz has been translated into Polish.

Your Replies

#1 On January 22nd, 2008 11:39 am David Zülke replied:

This is nonsense. Why not fix it properly by enabling standards mode for XHTML sent with application/xhtml+xml and the upcoming HTML5. That solves it properly, once and for all, without anyone having to touch existing markup. An Apache directive or two lines of code are enough to sent that header back for browser that send the same in an Accept request header (which IE would then have to do, of course).

#2 On January 22nd, 2008 12:21 pm Geoffrey Sneddon replied:

@David: What if there is a single bug that websites end up relying upon in IE8 in IE8 Standards Mode? Note that HTML 4.01 and CSS 2.0 (the current recommendations) are both too vague to be interoperably implemented. We then end up with the choice to break everything, or to add a compat. switch. Oh well, been there before.

#3 On January 22nd, 2008 2:42 pm Bb’s RealTech | Bobbing Heads and the IE8 Meta Tag replied:

[...] I was astonished to read the A List Apart article Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 and even more astonished to read compliance with the message from Eric Meyer, Molly Holzschlag, and the WaSP organization. How the mighty have fallen is so very cliché but, oh, how appropriate. According to Aaron Gustafson, who wrote the ALA article, the plan is rather than depend on DOCTYPE to trigger quirks and standard mode for page rendering–a necessity generated by Microsoft’s IE6 by the way–we all add a meta tag to our pages that locks the page into a specific browser rendering. For instance, the following would lock a page into IE8 rendering: <meta http-equiv=”X-UA-Compatible” content=”IE=8″ /> [...]

#4 On January 23rd, 2008 10:36 am Internet Explorer 8 und Webstandards « Internet « Quirksmode, Microsoft replied:

[...] Doch bekommen die Redmonder Angst vor der eigenen Courage und wollen einen neuen Meta-Tag einführen, um die Fehler, die mit dem IE 6 gemacht wurden, weiterhin im Web am Leben halten zu können. Ein klein wenig verständlich, dass MS die Geister beschwichtigen will, die es selber rief. Aber: Kann man wirklich Webseiten ernst nehmen, die nur für den IE6 designt wurden und bei modernen Browsern schlapp machen? Muss man als Webdesigner in den Meta-Tags wirklich Webstandards bewusst in den Metas aktivieren müssen, damit der Internet Explorer endlich einmal tut, was er tun sollte? [...]

#5 On January 23rd, 2008 12:39 pm Olly replied:

@David Zülke

This is nonsense. Why not fix it properly by enabling standards mode for … the upcoming HTML5.

They have, for HTML5 at least. See John Resig’s post on the subject.

#6 On January 24th, 2008 11:04 am Mr K PositionMakers replied:

I have to agree that IE always breaks something with new versions. Hopefully this starts to change in the near future (like NOW).

#7 On January 25th, 2008 4:51 pm La domo de karotoj » Nova meta-etikedo por norma sekvado replied:

[...] Ĉar Esplorilo ŝanĝas aferojn en ĉiu eldono kaj tio “rompas” iujn TTT-ejojn, Mikrosofto kunlaboris kun iuj (sed ne ĉiuj) WaSP-anoj liveri novan manieron per kiu la TTT-legilo povas certi pri la normeco de paĝo, per nova meta-etikedo. [...]

#8 On February 5th, 2008 6:12 pm Neues Meta-Tag | Geldblog replied:

[...] Hier der Link: ie8-will-see-the-smile socialize it Diese Icons verlinken auf Bookmark Dienste bei denen Nutzer neue Inhalte finden und mit anderen teilen können. [...]

#9 On February 16th, 2008 5:00 pm Matthias replied:

I don’t get it.

The problem is not a technical one, it’s a human one: No matter how much time you give developers to come around to proper HTML “on their own schedule” (as the Microsoft blog entry has it), some of them never will. Not if they can get away with shoddy work. You can’t fix that with a META tag.

It seems to me that you already learned this lesson with the Doctype Switch. As you write in your blog entry:

“The DOCTYPE switch assumes that if you are using a valid DOCTYPE for a “modern” language (e.g. HTML 4), you know what you’re doing and want the browser to render in standards mode.

That assumption could have worked out all right, had it not been for authoring tool makers who—with the best intentions and under pressure from us (the web standards community and WaSP, in particular)—decided to include valid DOCTYPEs in new documents by default, thereby crippling the DOCTYPE switch because it wasn’t an explicit opt-in.”

So the Doctype Switch failed because it fixed the wrong problem – and yet you think you can “fix” that with yet another strange feature? What will you do when that new feature also fails -as it must, because people never change-?

Microsoft’s (and our) money would be much better spent in training developers to write proper HTML. I’m surprised the WASP lost its sting.

Post a Reply

Comments are closed.