XHTML still harmful?
I'm starting a project where the client has mandated the use of XHTML 1.0 Strict. Now I'm wondering whether the problems described in Sending XHTML as text/html Considered Harmful are still current and whether I should try to convince the client that this (very strongly stated) requirement is counterproductive.
Does Internet explorer handle application/xhtml+xml correctly by now?
IE9 handles application/xhtml+xml , including SVG inside it, one of the main reasons to want to use this media type. (Otherwise, there's relatively little point in using it to date, as you get a bunch of scripting changes, and IE<9 incompatibility, in return for relatively little if any performance gain at the moment.)
I don't agree with Hixie that serving XHTML as text/html has ever been really harmful. Using the HTML-compatibility guidelines, XHTML poses no problems to any browsers since the ancient Netscape 4. Although it doesn't really get you anything on the client-side, it can be helpful to your own page handling workflow if you're working with XML processing tools. And the XML syntax rules, being stricter-but-simpler than HTML, are a good thing to author to; this gives the validator a chance to pick up on errors that are valid constructs in SGML/HTML but which are almost certainly not what you meant. (On the other hand, since the validator won't enforce HTML-compatibility guidelines there are a couple of places where it can let through well-formed-but-troublesome markup, most commonly self-closed <script> tags breaking the whole page.)
Specifically, to answer his points: /> and related SGML issues are only a problem to tools that really believe HTML is SGML—which is no browser ever, in the past. In the future, it is specifically allowed in non-XML HTML5.
Hiding scripts/stylesheets from 'legacy' (pre-HTML 3.2!) browsers hasn't been an issue for a decade or so: I came up with the mangled comment hack he (rightly) derides as ridiculous, but it was only an exercise; I never intended anyone to use it except in some strange hypothetical emergency. It's certainly not 'necessary' for using embedded scripts and stylesheets in XHTML-as-HTML... a straight //<![CDATA[ hack is enough if you need to be able to include < and & characters, and more commonly you don't even need that.
No-one actually wants to sniff for XHTML-as-HTML and treat it differently, so that whole section is moot. “Sending XHTML 1.1 as text/html is NEVER fine” has been changed by W3C (it now is fine after all), and XHTML 2.0 is dead.
So yes, use XHTML 1.0 Strict, or XHTML 1.1 or XHTML5, if you like. But until IE9 is your baseline browser (and that's not going to be the case for ages), you'll have to stick with text/html .
Internet Explorer 9 will handle application/xhtml+xml documents through a tag soup parser.
Internet Explorer 8 and earlier will prompt the user to save the document or open it in another application.
Internet Explorer 6 and newer all have significant market share (although this does depend, to some degree, on your market).
Nothing significant has changed as regards browser support for real XHTML for many years.
It is still far more trouble than it is worth unless you actually use XML parsers in your production chain (in which case, good luck persuading them to output XHTML that meets the HTML Compatibility Guidelines).
This depends on what you mean by "Internet Explorer".
For instance, IE6 is still from something like 2001 (that hasn't changed), and no, it still doesn't handle it correctly.
链接地址: http://www.djcxy.com/p/88764.html下一篇: XHTML仍然有害？