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

Mon Mar 12 10:39:32 PDT 2007

On Mon, 12 Mar 2007, Matthew Ratzloff wrote:
> >
> > Strict mode isn't versioning, per se; it's a toggle between two modes 
> > which was basically required to get around the problem of the 
> > standards not lining up with reality and the browsers being unable to 
> > both comply to standards and render legacy content.
> 
> It's tempting to think that browser makers will get it right the first 
> time, but I'm not sure I believe it.  <!DOCTYPE HTML> might introduce 
> headaches when Microsoft or Mozilla or somebody realize they've had a 
> bug in their rendering engine for a couple of years that people depend 
> on now. Does that DOCTYPE now become <!DOCTYPE HTML STRICT>?

No, we just fix the spec.

> What happens then when HTML 6 is introduced?

Nothing special. HTML6 will just be backwards compatible like HTML5 is.

> > HTML5 doesn't need such a rendering mode flag because it doesn't 
> > introduce incompatibilities (by design).
> 
> Sure, but can you guarantee that also for HTML 6, HTML 7?

Pretty much. The only version of HTML not to have done this was XHTML2, 
and it is pretty much dead on arrival.

If a future version of HTML really needs versioning, then the people who 
make it can add versioning. I think it would be a horrible mistake, but 
that's not our problem.

> Versioning is a great strategy if implemented well.

I fundamentally disagree. 

> Any reasonable implementation would have a base rendering engine and 
> then browser differences would extend off of it.  A new version would 
> mean you change only what differs between versions.

You still end up with dozens of codepaths to test. Testing one browser is 
a near-infinite amount of work, increasing the complexity is not workable.

Quirks vs Strict has already made the life of Web browser vendors FAR more 
complicated than necessary; adding yet more modes is simply not something 
any sane browser vendor would do.

> Like products, browser makers could set a cut-off date for new support 
> requests for older versions of HTML.  For example, when HTML 7 comes 
> out, browser makers wouldn't be obligated to correct HTML 5-specific 
> bugs anymore.  They would support, at most, maybe two versions (one 
> primary, one secondary).

They're not "obligated" to fix any bugs at all. They do it because they 
have to to render Web sites properly so that they get more users than 
other Web browsers. They'd continue doing so for as long as it made sense.

Now consider what it would take for someone to write a Web browser from 
scratch in 500 years in your system. Can you imagine the complexity of 
having to implement three dozen variants just to render content written 
from 2035 to 2080?

> In effect, I'm suggesting a structure like this:
> 
> --Base rendering engine
>   |
>   +- HTML 4 quirks mode
>   +- HTML 5 (renders HTML 4 strict as well)

I think you have a simplistic view of how browsers work. I recommend 
looking at the source of Mozilla or Webkit.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'