RE: ISSUE-54 (html5-doctype-vs-xslt): XSLT 1.0 can not generate HTML5 documents [HTML 5 spec]

> -----Original Message-----
> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
> Behalf Of Simon Pieters
> Sent: Friday, September 05, 2008 4:23 PM
> To: Justin James; 'Jonas Sicking'
> Cc: 'Boris Zbarsky'; 'Karl Dubost'; 'HTML WG'
> Subject: Re: ISSUE-54 (html5-doctype-vs-xslt): XSLT 1.0 can not
> generate HTML5 documents [HTML 5 spec]
> 
> 
> On Fri, 05 Sep 2008 20:04:16 +0200, Justin James
> <j_james@mindspring.com>
> wrote:
> 
> > I agree, but at the same time, "deprecated" has got to mean
> something,
> > too.
> 
> Not for UA implementors, really.

Agreed, but it should mean something for *authors* and the creators of authoring tools. UAs are free to accept any garbage code they want, and I believe that not doing so would result in a significant loss of market share. But at the same time, we need to encourage authors and creators of authoring tools to stop cranking out this nonsense code. Someone marking their HTML as "HTML 5" (however the DOCTYPE issue plays out) should not work the way the author intended if they use the <font> tag, for example, whether it be that the content disappears, or the tag is ignored, or whatever.

So my proposal on the topic is such:

* Continue to allow browser vendors to define their own "quirks modes" or "relaxed validation modes" or whatever. They can apply it to whatever they want to, *except* code that has been properly marked at "HTML 5".

* Continue the progress that has been made in the HTML 5 spec to define error handling, so that it is clear to all parties exactly how invalid code will be handled, and to *not* expect a document clearly labeled as "HTML 5" to be as loosey-goosey with error handling as browsers allow non-HTML 5 code to be.

> > Besides, why should we be concerned with what browsers do in "quirks
> > mode"? Defining how a browser works in "quirks mode" is not our
> domain;
> > that browser's developers are in charge of that.
> 
> The point of having standards is interop. More than half of the Web is
> in
> quirks mode. It seems silly to me to leave that portion undefined.

I think that there is a huge risk in this group defining "quirks mode." For one thing, I don't think that we want o legitimize it. For another, I think that what we call "quirks mode" is not something that every HTML authors are deliberately using, they simply use it because years of loose code handling on the part of UAs has allowed a ton of bad copy/paste code to get around to the point that people that that it is actually good code.

The proposal outlined above is designed to accomplish the following goals:

* Not break existing content.

* Provide a "safe haven" for HTML to not share the same problems that previous HTML's have had, in terms of poorly defined or undefined handling of sloppy code.

* Redefines expectations of HTML authors... "if you are going to claim to write HTML 5 code, then write proper HTML 5 code, otherwise, keep churning out slop if you really want to."

* Provides a clearly defined path to finally escape deprecated/obsolete syntax once and for all... "I don't care if <font> works in 'quirks mode' or on browser XYZ if you claim to be 'strict/transitional', if you are going to claim HTML 5, then it simply won't work, end of story."

Personally, I think that authors will quickly see that the advantages of claiming HTML 5 and then using it properly will more than offset the time spent learning to use it correctly, since most of the "boo hoo, browser ABC is 'non-compliant'!" complaints are really related to two browsers interpreting the same piece of invalid code quite differently. :)

J.Ja

Received on Saturday, 6 September 2008 05:24:22 UTC