W3C home > Mailing lists > Public > public-html@w3.org > September 2008

RE: Is "breaking the Web" with HTML 5 a non issue?

From: Justin James <j_james@mindspring.com>
Date: Mon, 22 Sep 2008 13:15:09 -0400
To: "'Andrew Sidwell'" <w3c@andrewsidwell.co.uk>
Cc: <public-html@w3.org>
Message-ID: <02f601c91cd6$c4172500$4c456f00$@com>

> -----Original Message-----
> From: Andrew Sidwell [mailto:w3c@andrewsidwell.co.uk]
> Sent: Monday, September 22, 2008 12:47 PM
> To: Justin James
> Cc: public-html@w3.org
> Subject: Re: Is "breaking the Web" with HTML 5 a non issue?
> Justin James wrote:
> > Thanks!
> >
> > This seems like less than ideal behavior. What is the point of
> > UAs don't make any kind of decisions based upon it?
> There isn't much of one; it's a talisman.  Certain doctypes put layout
> engines into "Standards mode", rather than "Quirks mode".  <!DOCTYPE
> html> is the shortest string that triggers standards mode in all
> browsers, which is why it's the HTML5 doctype.  Browsers have never
> switched how they behave based on the version of HTML being used, and
> none of them intend to.

Then let's throw out DOCTYPE. I've been using HTML for over 10 years and
faithfully been including the DOCTYPE that matched the code I was trying to
write. Nice to know that this was wasted effort. By continuing to include
the DOCTYPE farce, we are just giving innocent HTML authors like myself the
false belief that their code will be interpreted as they expect it to be.

> In short, yes; the suggestion to junk backwards compatibility is the
> polar opposite of how the spec (and the Web!) has been developed to
> date.  HTML5 is a specification of how to handle text/html and
> application/xhtml+xml documents, not how to handle a subset of
> text/html
> with a certain magic string at the beginning.

I'm not asking to junk backwards compatibility; I am looking for a way for
existing content to not be interpreted in the slightest.

> To have an "HTML 5" mode and a "non-HTML 5" mode would be roughly
> equivalent to shipping two web browsers (parsers, DOM implementations,
> ...), something which most browsers are not interested in doing (IE
> being the exception).  Not to mention that saying "parse stuff without
> this doctype according to this other specification, which specifies no
> usable parsing rules" is not useful to anyone in the slightest.

So what? They already have the existing parsers, all they have to do is
include new parsers, which they would need to write anyways. In a nutshell,
this is asking for the addition of 1 - 10 lines of code at the beginning of
the parser, to perform the toggle.

You are right that my idea of the fallback rules was flawed; I think that
Phillip's suggestion is far superior.

So far, you have not really said *why* this is not a good idea, just simply
that there is inertia against it. Fact is, there is a lot of inertia behind
the <font> element (for example), doesn't mean that the spec needs to
support it. If there's a lot of inertia behind ignoring DOCTYPE, fine,
ignore it... unless it explicitly calls for HTML 5. The alternative is to be
beholden to mistakes people made 15 years ago. I thought that a "fresh
beginning" was a lot of what HTML 5 was supposed to be about; the new error
handling items certainly hammer that point home.

So let's either ditch DOCTYPE, or have it mean something. But to continue on
with it being merely a "talisman" is not a good plan.

Received on Monday, 22 September 2008 17:16:00 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC