[whatwg] Versioning (was: Re: Using the HTML5 DOCTYPE as a new quirksmode switch)

[Robert Brodrecht]

liorean wrote:
> Well, I have several issues with that:
> - First of all, that developers have low awareness of the HTTP side of
> the web. Most web developers are happily ignorant about HTTP headers,
> and even if they know about them, it's mostly limited to some specific
> problem, such as cache control headers.

To deliver real XHTML, developers are supposed to know about content-type
headers.  I don't think it's asking too much of the upper-eschalon of web
developers to add a header for IE.  Of the ~50% of people (according to
Chris Wilson) that have DOCTYPE, I'm sure there is a good portion that
have it because the WYSIWYG editor put it there.  Since those ship with
the ability to create compatible designs, it's not an issue for them.  For
those that work in quirksmode or just copy/pasted in a doctype from a
tutorial, it is certainly not an issue.  Having the extra standards
support is an issue for those of us who hand-code our sites.  If someone
is purposefully triggering standards mode, I would hope they had a clue
about HTTP headers.

> - Second, that we already have MIME type switching (tagsoup/XML
> modes), Content-Type: ...;charset=xyz switching (and corresponding meta
> element), various cache behaviour switching, and DOCTYPE
> switching. Please don't add yet another type of switch, just reuse the
> most practical one of those already present.

The problem is that there isn't a practical one to reuse.  I would hope
the IE Team would have been smart enough to think of looking for a
complete DOCTYPE first.  They asked for "another opt-in" (presumably other
than the doctype opt-in).

> - Third, it has to work when there's no HTTP headers, e.g. from
> network shares or the file system.

Real XHTML turns to tag soup when there is no header.  This can have quite
a few unexpected consequences when a real XHTML document is downloaded and
viewed not-over-the-network.  At least with an IE-only header, it would
only affect viewing the page locally in IE (unless the meta http-equiv tag
was present, then it should display properly).

> Something I'm very grateful for here, is that XHTML documents don't have
> this problem. There is no quirks mode in XML in any XHTML aware browser.
> And iew is not an XHTML aware browser. The super-standards mode will be
> the only mode available in XHTML douments.

The fact that IE doesn't support real XHTML is why real XHTML* never
gained critical mass.  I don't think we'd be working on HTML 5 if IE would
have had support for real XHTML, even if it was buggy / semi-quirky
support.

> As for HTML 4.01 or XHTML1.0 as text/html, that's an area I disagree.
> The text/html media type is tagsoup for all browsers. A certain set of
> doctypes act as standards mode switches, but only as token strings, not
> by actually meaning the document conforms to any particular HTML
> specification.

With HTML and fake XHTML, it is the job of the developer to make sure that
code conforms to a particular specification.  There are quite a few people
out there who care about delivering well-formed, quality code, even if
their page will still render when there are syntax errors.  There are
quite a few of us who aren't lazy (even if we make mistakes now and
again).

> There is no meaning in those strings to any of the
> browsers, except for their triggering different rendering modes.
> HTML2.0, HTML4.01 of XHTML1.0 are all the same HTML if you ask the
> browser. This mode is just another one added to the set of modes
> provided by one particular browser.

There is (and ought to be) meaning to the authors.  The spec we are
working on now will have a text/html serialization.  When I start writing
for HTML 5, I will do my best to conform to the spec by writing valid
code, and will write well-formed code because I take pride in the work I
do.  I do the same thing with HTML 4.0 (and would do the same with fake
XHTML if I didn't believe it was ideologically broken... instead I don't
use it at all).  Just because it renders with a tag soup parser doesn't
mean I shouldn't be able to reap the benefits of better standards-based
rendering in IE.  So, it'd be super great if whatever switch the IE Team
decides to use is backwards compatible.

* When I say "real XHTML", I mean XHTML served with application/xhtml+xml
Content-type headers.
-- 
Robert <http://robertdot.org>