On my birthday, two years ago, the W3C released a NOTE: XHTML Media Types. Great, a standard for the hell of media types in XHTML coming from the W3C. Not really, it is just a NOTE. It doesn't represent consensus (working group that agrees with each other) within the W3C and people from outside the W3C don't like it either.
Sensible people think that MIME types matter and DOCTYPEs don't. Those people are also well aware that when Internet Explorer 6.0 is the new Netscape 4 (not in support, in browser market) we can take our HTML 4.01 Strict pages without optional end tags and convert them within 5 minutes to valid XHTML 1.1 Strict pages with required end tags. Those people are also well aware that that day will probably never come and that when Internet Explorer 6.0 is the new Netscape 4 we get Internet Explorer 7.0, which will be the new Internet Explorer 6.0.
Anyway, don't link to that document and quote from it other then work in progress it isn't near normative for miles. (Normative means standard, not informative.)
Another disgrunted W3C fan. Join the club.
"...we can take our HTML 4.01 Strict pages without optional end tags and convert them within 5 minutes to valid XHTML 1.1 Strict pages with required end tags. Those people are also well aware that that day will probably never come..."
I guess it's just a hard pill for a lot of people to swallow, especially after all the years of championing the benefits of XHTML. Now that large sites are finally coming around and redeploying with (typically mangled & invalid) XHTML, you can't exactly turn around and say without losing credibility: "Whoops... we miscalculated. You should have just gone with valid HTML and CSS instead... sorry." It's easier to just perpetuate an illusion. An illusion that a whole lot of well-intentioned people bought into.
The one thing I don't understand is why the W3C keeps recommending XHTML for everyone. What's the point of sending bad HTML? You don't get any real benefits from XHTML markup as long as you send it as text/html, and you have to do that if you want to reach a larger audience.
Thanks for explaining that, Anne. This is an issue which I also didn't understand until now. But if you ask me, the W3C should still get their business right and organized.
I am really starting to agree that sending XHTML as text/html is a bad idea for more reasons than one. And like it has been mentioned, the advantages are not at all clear.
I still like sending XHTML to compliant user agents, though! Probably more technical interest than practicality. :-)
The thing that bugs me:
XHTML documents served as 'text/html' will not be processed as XML, e.g. well-formedness errors may not be detected by user agents. Also be aware that HTML rules will be applied for DOM and style sheets
The text/html media type is suitable for transmitting XHTML 1.0 following Appendix C. I have a (tiny) in-house XHTML UA. There is no reason why it should not apply XHTML rules to text/html content that it can expect to be XHTML (i.e. the websites it is configured for). Content negotiation drives cachability way down, so that's not a good idea. But as far as the WG is concerned, the official policy is "text/html should never be treated as XHTML" (it's also been expressed elsewhere by the WG, but I can't dig up the link right now). This seems to be at odds with the text/html RFC.
Do you perhaps mean this email: Re: Sniffing XHTML sent as text/html?
That's the one, thanks. I don't see any basis for equating "old UAs will treat it as HTML" with "new UAs must treat it as HTML". It's a logical leap that I have never seen justified.
Shhh, MikeyC, let it be. Web designers produce borked XML; modern browsers quietly un-bork their websites for them; people get to feel good about themselves because they're "forward compatible." Everybody's a winner! Why upset the apple cart?