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