Re: HTML version issue summary?

Versioning is like a vendor-neutral opt-in hook.  Browsers can then  
use their own opt-in hooks and use the vendor-neutral hook once they  
are confident in their compliance with the spec.  Theoretically IE  
might do something like this with my proposal:

IE 8 ships with partial HTML5 support, uses custom opt-in #1
IE8.1 ships with more complete HTML5 support, uses custom opt-in #2
IE9 is the point where MSFT decides they've nailed it, now they use  
the HTML5 version as opt-in #3
IE9.1 starts adding more features for future HTML versions or maybe  
has to tweak existing HTML5 a tiny bit to deal with some quirks, uses  
custom opt-in #4

etc.

dave
(hyatt@apple.com)

On Apr 24, 2007, at 6:04 PM, David Hyatt wrote:

>
> 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 necessary.
>
> 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.
>
> dave
> (hyatt@apple.com)
>
>
>
>

Received on Wednesday, 25 April 2007 01:17:01 UTC