Anne van Kesteren

'application/xml' in Internet Explorer

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:

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!


  1. What is the trick? The xhtml.xsl?

    Posted by Mark Wubben at

  2. 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.

    Posted by Asbjørn Ulsberg at

  3. 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...

    Posted by Charl van Niekerk at

  4. apparently it doesn't work too well with ASP/JSP, although i haven't tested it myself.

    some other things to note:

    1. it doesn't work with the XHTML1.1 DTD. (it chokes on an entity reference)
    2. still chokes on content-type application/xml+xhtml

    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!

    Posted by Dean Edwards at

  5. apparently it doesn't work too well with ASP/JSP

    neither do I...

    Posted by Ben at

  6. 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...

    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.

    Posted by Anne at

  7. 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. :-)

    Posted by Asbjørn Ulsberg at

  8. 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.

    Posted by Anne at

  9. 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.

    Posted by Andrew Clover at

  10. … media type application/xhtml+xml? they forget to mention that Internet Explorer chokes on XML errors so it certainly uses a different parser…

    Posted by A FAQ about (X)HTML - Anne’s Weblog about Markup & Style at