Ok, so the news was spread already that Dean Edwards unleashed a new tool:
application/xml in Internet Explorer. I did know it, but I wasn't really sure if I should mention it, although Dean told me it was fine. I have done a little testing with his experiment and optimized the example a bit. Note that the info menu from Mozilla has a problem, the MIME type really is
application/xml, but Mozilla says it is the evil MIME type
text/xml. Mozilla does most of it correct although it fails the character encoding test; it doesn't give a fatal XML error when the character isn't an
utf-8 character. Internet Explorer does this right.
The only problem I encountered, which doubled the amount of test cases, was that IE only loads the external XSLT file when the pseudo-attribute
TYPE was set to
text/xsl, which is not the appropriate MIME type for XSLT files. (This is needed for Internet Explorer to "support" XHTML.) According to the specification, either
text/xml (evil) or
application/xml should be used for XSLT. I did actually use
application/xml, but when I point to it as
application/xml, so changing the pseudo-attribute to
application/xml, it doesn't work anymore. But maybe you don't really care about matching
MIME types as much as I do. Anyway, here are the test cases:
text/xsland a missing
text/xsland an invalid character.
text/xsland some CSS applied.
application/xmland a missing
application/xmland an invalid character.
application/xmland some CSS applied.
The only thing that bothers me is that the actual MIME type for XHTML is
application/xhtml+xml, but maybe that doesn't really matter.
If you are going to test this yourself, add the following to either httpd.conf or .htaccess:
AddType application/xml .xml
The good news besides the above is that it works in Internet Explorer 5.0, 5.5 and 6.0!
What is the trick? The
application/xml is a whole bunch better than
text/html, but I don't really see why we should send XHTML documents as
application/xml to a browser that doesn't parse the shait as XML anyway...
It's probably great for people serving static web pages, but if you have access to PHP, ASP or some other technology to serve your web pages through, doing content negotiation is imho somewhat better. It's at least not worse than the XSLT hack.
Very smart and simple. I can't believe I didn't think of this myself. Congratulations, Dean!
I was thinking of using this myself, but then the following question came up: How does this fit with Google? Probably not good. Back to content negotiation...
apparently it doesn't work too well with ASP/JSP, although i haven't tested it myself.
some other things to note:
i see it as more of a joke than a serious solution but i'd be interested in seeing people taking my experiment further.
ps: anne, you were allowed to blog this one!
apparently it doesn't work too well with ASP/JSP
neither do I...
but I don't really see why we should send XHTML documents as
application/xmlto a browser that doesn't parse the shait as XML anyway...
I don't really see the problem? It seems that Internet Explorer has a better XML parser than Mozilla, since it does give a fatal error on invalid characters.
Anne, Internet Explorer uses MSXML 3.0, which is nothing but an OK XML parser. Anyway, IE doesn't actually show the final markup as XML, but as SGML. Therefore, I don't understand the point of serving it as
application/xml. It's funny that it can be done, but I don't see it as very useful.
If you could serve XHTML documents as
application/xhtml+xml to every browser, without any content negotiation, that would indeed be a step forward. This, if considered a step, is not forward, but maybe to the side. :-)
Before I leave: have you seen the test cases? Internet Explorer does give a parse error when your document is not well-formed. I think that is an advantage.
it doesn't work with the XHTML1.1 DTD. (it chokes on an entity reference)
Not sure if this is the problem in this case, but refusing to parse the XHTML 1.1 DTD is not an error, as the XHTML 1.1 DTD (the external entity xhtml1_special.ent in particular) is broken. It's amazing it got to standardisation and no-one noticed, but there you are.
This has been fixed in XHTML Modularization Second Edition; until this is standardised (it's currently only Working Draft) DTD validation for XHTML 1.1 is a dead loss. This is one of the reasons I'm avoiding XHTML 1.1 for now.
… media type application/xhtml+xml? they forget to mention that Internet Explorer chokes on XML errors so it certainly uses a different parser…