[whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

Mihai Sucan mihai.sucan at gmail.com
Sat Mar 10 05:41:15 PST 2007

Le Sat, 10 Mar 2007 14:27:32 +0200, Alexey Feldgendler  
<alexey at feldgendler.ru> a écrit:

> On Sat, 10 Mar 2007 11:16:09 +0100, Mihai Sucan <mihai.sucan at gmail.com>  
> wrote:
>> Alexey, actually I'm skeptical about this. First impression I had  
>> reading the first post was "hey, do we need yet another switch?".  
>> What's "super-duper" standards mode after all?
>> How will tutorials look:
>> 1. For quirks mode use no DOCTYPE.
>> 2. For standards mode use one of the following DOCTYPEs:
>> "http://www.w3.org/TR/REC-html40/strict.dtd">
>> 3. For "super-duper" standards mode use the following DOCTYPE:
>> <!DOCTYPE html>
> The tutorials will just say "Use <!DOCTYPE html>".

Those are the tutorials for beginners. I was talking about advanced  
tutorials, for developers who want to know "gory" details.

>> My point is: we either want it, or not, what we have today called as  
>> "standards mode" is also buggy (each browser has its own set of  
>> rendering bugs). If IE adds the third level of rendering, then we have  
>> yet another DOCTYPE switch.
>> Microsoft needs to make the improvements in the current standards mode  
>> - as they did now with IE 7. They need to continue this.
> The reason why modes other than the best standards mode exist is that a  
> significant number of existing documents are written while keeping the  
> non-standard browser behavior in mind, and it's unacceptable to change  
> the rendering of those documents dramatically.
> Actually, the best standards mode available is the only right mode to  
> work in. The other modes are only supported for backward compatibility  
> with existing documents.

Right, and we already have one. It's the one we trigger right now with  
both of the following DOCTYPEs:

<!DOCTYPE html>

It's called "standards mode" for a reason. All the browsers fix and  
improve their standards mode rendering.

Here's how I see things (there are many details, which I probably forgot  
about right now):

(leaving aside the Netscape legacy)

1. There's IE with quirks render mode: ugly, damaged, really bad rendering.
2. There are other browsers (Opera, Geckos, WebKits) which also have  
quirks rendering mode, mimmicking and reverse-engineering quirks mode from  
3. There's standards mode in IE which is a tad better currently, compared  
to its quirks mode.
4. There's standards mode in the other browsers as well, which is far  
ahead compared to IE "standards" mode.
5. The other browsers, having little market share, have the liberty of  
improving their standards mode rendering, without annoying many users.  
Their users are more aware of the problems, why sites break, etc.
6. There are millions of pages relying on broken quirks mode rendering  
 from IE (and legacy Netscape 4).
7. There's a new wave of "modern/cool/awesome" sites (including mine)  
relying on broken standards mode rendering in IE 6 and IE 7 (I still  
dislike it's rendering).
8. If Microsoft improves standards support in IE.next, in standards mode,  
it breaks existing modern sites.

So, this proposal sounds like "why not make this DOCTYPE switch to an even  
stricter standards rendering mode in IE.next? then we can improve IE  
without breaking existing sites". What this means, is that people will  
create even more modern sites, which will use this new DOCTYPE and the  
improved rendering engine (which will never be perfect). It's going to be  
a loop: newer sites will rely on the newer rendering mode. So, with each  
new version of IE (released every 5-10 years), we will have a new DOCTYPE,  
and a new rendering mode?

Instead of using this DOCTYPE switch, I was even thinking of conditional  
comments, DOM document property, etc. Yet, other methods only add  
complications. If Microsoft considers adding a new rendering mode as a  
must, such that it will not break many sites, then this DOCTYPE is an  
elegant solution. History will repeat itself, no matter how elegant the  
solution might be.

Probably I don't really like this proposal very much only because it's a  
solution for *this* very moment, forgetting the fact that rendering bugs,  
and sites that rely on the bugs, will exist forever (a constant problem).

ROBO Design - We bring you the future

More information about the whatwg mailing list