W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: HTML version issue summary?

From: David Hyatt <hyatt@apple.com>
Date: Tue, 24 Apr 2007 18:04:39 -0700
Message-Id: <ECB91171-2A1B-428C-9FB9-2454C92CD0E0@apple.com>
Cc: Dan Connolly <connolly@w3.org>, public-html@w3.org
To: Maciej Stachowiak <mjs@apple.com>

On Apr 24, 2007, at 5:37 PM, Maciej Stachowiak wrote:

> Did you read my message about why versioning (if we have it) should  
> be in an attribute, not the doctype? Short version is that the  
> doctype approach doesn't work for XHTML or compound documents (and  
> as Sam Ruby just pointed out, it doesn't work for HTML/XHTML  
> embedded in RSS or Atom feeds).

I did.  I don't think the feeds case is that relevant, since I think  
there is less of a backwards compatibility issue there.  In my  
opinion a browser engine could just use its latest HTML version  
automatically when displaying feeds.

>> (5) I do not think the spec should attempt to say how browsers opt  
>> in to HTML5.  Microsoft should be allowed to design their own  
>> mechanism for this.
> How could we possibly have valid test cases for the spec if it  
> doesn't define at least one condition under which you have to treat  
> content as HTML5?

I think you're misunderstanding me.  The purpose of the opt-in is to  
have a way to include partial HTML5 support in a shipping product  
without affecting backwards compatibility.  Once a browser fully  
supported HTML5, they could drop the browser-specific opt-in and  
start using the DOCTYPE/version as the opt-in.

So in effect the version does say "You must use HTML5 if you support  
it" but since "support" can take a while to become complete, a  
browser should be able to use an opt-in mechanism that is independent  
of the version string until such time as they consider their HTML5  
support to be ready.

Therefore we would have valid/interoperable test cases just by using  
the HTML5 DOCTYPE/version.

If/when MSFT says what their opt-in is, we could add it to the test  
cases if we think testing their partial implementation is valuable.

> How can you have interoperability if every browser can have a  
> different opt-in? I

The DOCTYPE/version switch provides interoperability.

Let's stop trying to frame this problem in such general terms.  We  
all know that there is only one browser that is going to need to opt  
in. This isn't a problem that has to scale to multiple browsers.

> I think the spec should require at least one condition (perhaps a  
> combination of doctype and version attribute) that requires content  
> to be treated as HTML5. I am ok with the spec not requiring or  
> forbidding handling legacy content (no doctype or older doctype) as  
> HTML5.

As I said above, I think browsers should have the option of producing  
experimental support for HTML5 without being required to include it.   
If there is a DOCTYPE/version specified, then I can see how a browser  
would not want to honor it until they were highly confident that  
they'd fully implemented HTML5.

But yes, the DOCTYPE/version would effectively mean the content  
should be treated as HTML5 (once the browser has decided their  
implementation is ready to be enabled).

Note that I do *not* agree with revving the HTML5 version just for a  
browser's benefit.  If a browser vendor isn't confident that they've  
fully supported HTML5, then they should not use the doctype/version  
switch as their opt-in mechanism.

>> (7) I think .innerHTML is a red herring.  All parsing happens in  
>> the context of some document, so knowledge of versions/opt-in will  
>> be present.  This happens today already with inline style  
>> attributes (where a browser has to know whether the fragment is in  
>> quirks/strict mode even when parsing in order to decide whether  
>> CSS will be lax or not).
> I think you misunderstood the messages about this. If an Atom or  
> RSS feed contains HTML fragments, and these are combined into an  
> HTML document template, the versioning that applies will be that of  
> the containing HTML template. How do you author fragments if you  
> don't know what version will be applied to them? The snippets  
> probably came from some blog post on the web, which was likely an  
> HTML page with a version that might not match the template you are  
> pasting into.

I'd be curious what Microsoft's opinion is here.  I am not convinced  
that this problem space needs the same rigor... i.e., I think it  
might just be ok to use the latest version of HTML that your engine  
supports when displaying feeds.  I am possibly being naive here, in  
which case maybe a version attribute instead of a doctype would be  

I'm pretty flexible about how to define the version.  I do think we  
should specifically call it 5.0.  Whether it's an attribute or  
doctype does not matter to me that much.

Received on Wednesday, 25 April 2007 01:04:43 UTC

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