- From: Smylers <Smylers@stripey.com>
- Date: Wed, 20 Jan 2010 18:04:09 +0000
- To: public-html@w3.org
Leif Halvard Silli writes: > Smylers, Wed, 20 Jan 2010 16:14:59 +0000: > > > Leif Halvard Silli writes: > > > > > Tab Atkins Jr., Tue, 19 Jan 2010 12:36:42 -0600: > > > > > > > On Tue, Jan 19, 2010 at 12:23 PM, Leif Halvard Silli: > > > > > > > > > So, with HTML5 we get two kinds of text/HTML: "real" text/HTML > > > > > and XHTML text/HTML. The latter gives us much more freedom > > > > > than HTML5. > > > > > > > > The latter does not exist. If a file is served with the > > > > text/html mimetype, it is an HTML document, and is processed > > > > according to HTML rules. ... There is no longer any such thing > > > > as "XHTML served as text/html". > > > > > > The W3 validator allows me to validate a XHTML document served as > > > text/HTML. > > > > The validator isn't the canonical source of what is permitted; where > > the validator and a spec differ at least one of them is buggy. > > If we are permitted to serve XHTML as text/HTML, then it makes sense > be able to validate such documents as well. Sure. But we aren't, in general, permitted to serve such documents. Or at least such documents will be interpreted by user-agents as text/html. So it only makes sense to check them against the rules for valid text/html. > > When content is being served in a way which will cause all > > conforming user-agents to treat it as one thing, how is it useful to > > check its validation as something else? > > Quite. Because, as you know, XHTML and HTML are quite close to each > others. Close, but not identical. And where there are differences, serving as text/html will cause the document to be interpreted using the HTML rules. That it happens to conform to a different (though similar) language in which a portion has a valid meaning doesn't affect that: it still either conforms to HTML or it doesn't. > > Regardless, a change in W3C Validator behaviour cannot affect what > > is permitted in HTML5. > > My point was merely that if HTML5 refuses to become more relaxed about > extensions, HTML5 is very relaxed about extensions: if a community agrees that a particular extension is relevant to them, then it's permitted. (Though admittedly that's more a description of how things are the real world than any policy by HTML5; it couldn't really be otherwise.) So if a knitting community come up with a mark-up language for embedding knitting patterns in webpages, and that community have HTML user-agents which interpret that language (maybe through a browser plug-in), then it's valid for other members of that community to serve pages which makes use of it. > then there exist another, parallel technology - namely XHTML served as > text/HTML. But there isn't. In doing so you are explicitly instructing user-agents that the content is HTML and should be interpreted as such. What they do with your content is defined by HTML (and any extensions they choose to recognize). If you choose an extension which your user-agent isn't aware of, but the extension may safely be ignored, then the page will still be interpreted correctly. And it will be valid HTML5+your extension. That's probably all that matters. Of course it won't be valid HTML5. But that isn't particularly relevant to what you're serving. If it happens to be valid XHTML5 (or Befunge, or whatever), it _still_ won't be HTML5. Smylers
Received on Wednesday, 20 January 2010 17:51:37 UTC