Re: HTML version issue summary?

Hey Dave,

On Apr 24, 2007, at 5:16 PM, David Hyatt wrote:

> (2) I think it's poor design not to include specific version  
> numbers to identify which spec an author wrote the content for.   
> Even if we never use the version number for anything, even if  
> alternative browsers support HTML5, even if the doctype says  
> HTML3.2, etc., it's still good language design to identify the  
> specific language version.  I would like the version string to be:
>
>  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 5.0//EN">
>
> thus specifically identifying 5.0 in case we decide to do a 5.1,  
> 5.2, etc..

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).

> (3) I think browsers should be allowed to support HTML5 without any  
> opt-in switches if they choose to.  Obviously alternative browsers  
> can more easily support HTML5 without requiring a 5.0 doctype or a  
> specific opt-in mechanism, and the spec should not prohibit that.
>
> (4) I think IE's opt-in should be independent of DOCTYPE until such  
> time as they are confident that they have HTML5.0 fully implemented  
> and supported.  Then one could imagine the doctype being used as  
> the opt-in.
>
> (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? How can you have interoperability if every browser  
can have a different opt-in? I fundamentally disagree with this, 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.

> (6) I think XHTML is a red herring.  Realistically opt-in support  
> for HTML5 is an IE problem, and we can cross the compound document  
> bridge when Microsoft decides to add support for the XHTML MIME  
> type.  Everyone who does support XHTML will obviously just support  
> HTML5 features as part of XHTML support.  Let Microsoft decide how  
> they want to opt in to an XHTML world when they implement support  
> for it.  It's not our business to try to tell them how they should  
> do that.

Don't we want the XML version of HTML5 to be interoperable in the  
browsers that do support it, even if Microsoft doesn't? If so, and if  
identifying version 5 is important for "poor design" reasons like you  
stated above, as opposed to just for bugmode detection, then HTML5-as- 
XML needs a version identifier. And ideally we should use the same  
one for the HTML and XML serializations. It does not make sense to  
have different version identifiers between XML and HTML serializations.

> (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. If  
this implies different handling, then RSS readers that format the  
feed as HTML will break. Google Reader and Safari and IE's built-in  
RSS support work that way, so this is not a contrived use case. How  
do I get my blog content authored to IE8 to show up properly in RSS  
readers that use IE9 bugmode instead of IE8? Or vice versa? Also  
consider aggregating multiple RSS feeds in one HTML page.

Regards,
Maciej

Received on Wednesday, 25 April 2007 00:37:06 UTC