- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 25 Jul 2009 23:37:18 -0600
- To: Larry Masinter <masinter@adobe.com>
- Cc: Ms2ger <ms2ger@gmail.com>, Karl Dubost <karl+w3c@la-grange.net>, HTML WG <public-html@w3.org>
On Jul 25, 2009, at 10:54 PM, Larry Masinter wrote: >> But perhaps a different fruitful way to think of this is to make it >> definitional, rather than a matter of conformance requirement. > > Yes, that was my point. >> A resources served as text/html *is* (possibly invalid) HTML, >> and *is not* XHTML. > > Exactly, at least "on the web". Perhaps the "architecture of the > web" document doesn't make the relationship between MIME types > and languages clear enough? I think making this definitional is different from making it implementation advice. (I'm not even sure how this particular issue could be recast as "implementation advice"). But making it a definition rather than a conformance criterion makes sense to me. In a way, it's nonsensical to say that an XHTML document sent as text/html is not a conforming XHTML document, because the intent of the spec is that there's no such thing as an XHTML document sent as text/html. >> and not by particular DTD declarations or certain uses of slashes, or >> whatever other things people may mistakenly think makes a document >> XHTML. > > In lieu of an external indicator (if one isn't available), and > in some situations where mislabeling has been common, additional > heuristics are often applied, leading to content type sniffing, > and poor interoperability (because one language was intended > but the wrong one implied.) That has been indeed true in some situations, though I don't believe there's ever been an actual client that content sniffs to tell the difference between HTML and XHTML, other than validators. Part of the intent here is to get validators and content producers aligned with the way HTML consumers have been doing things. Regards, Maciej
Received on Sunday, 26 July 2009 05:38:53 UTC