- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Wed, 20 Jan 2010 20:24:46 +0100
- To: Smylers <Smylers@stripey.com>
- Cc: public-html@w3.org
Smylers, Wed, 20 Jan 2010 18:04:09 +0000: > 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: >> 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. If it only were so well. If SGML-inspired HTML could be extended the same way XML-rooted HTML can, then it would be so well. >>> 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. Of course it is interpreted as text/HTML. > 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. XHTML is included under the umbrella "HTML": "HTML is the family name for the group of languages that form the lingua franca of the World Wide Web." http://www.w3.org/MarkUp/Activity >>> 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. The evangelist. I can only repeat what I said. What I hear from (I don't bother to mention names) is not relaxed, it is frantic. And frankly, a validator that refuses to validate XHTML served as text/HTML is a little bit frantic as well. Although, by all means: I do see that it has a (theoretical) point. (A more fruitful approach would be to validate such documents as the polyglot document they are clearly intended to be.) >> then there exist another, parallel technology - namely XHTML served as >> text/HTML. > > But there isn't. I forgot what Sam uses to say - something about nuances of angle wings. > 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). Of course. XHTML documents served as text/HTML will be parsed as text/HTML. > 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. I don't know where you take your anticipation from. > 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. One of our groups goals is to not pursue theoretical purity etc. -- leif halvard silli
Received on Wednesday, 20 January 2010 19:25:20 UTC