- From: David Hyatt <hyatt@apple.com>
- Date: Tue, 24 Apr 2007 18:16:58 -0700
- To: Maciej Stachowiak <mjs@apple.com>, Dan Connolly <connolly@w3.org>
- Cc: public-html@w3.org
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