This is text/html

Volume 7, Issue 9; 18 Jan 2004; last modified 08 Oct 2010

This essay is served as text/html. It is essentially the same as the application/xml version:

Nothing will ever be attempted, if all possible objections must be first overcome.

Dr. Johnson

This essay is served with the MIME type “text/html”. If you’re reading this, then your browser did the right thing.

In the course of recent public debate on the appropriateness of recovering from well-formedness errors in XHTML, Mark Pilgrim caught me serving content that, at least by some metrics, purported to be XHTML and was not well-formed. (In fact, the server said it was “text/html” content so it was, by that metric, not in error, though it was clearly not “correct” either.)

I’m sticking to my guns and remaining a “draconian.” So David Carlisle challenged me to start serving my essays as “application/xml”. That would pretty much guarantee that the browser would report any lapses of concentration that caused me to accidentally generate markup that wasn’t well-formed.

In general, I expect that there are still far too many people using browsers that don’t know what to do with application/xml content to make it practical to serve it exclusively. But I’m not sure that’s true and it may in particular not be true you, my personal audience. (Have I thanked you recently for taking the time to read my ramblings? Thanks!)

So this essay is an experiment. If you can’t read the application/xml version (or the application/xhtml+xml version) of this essay but you can read this version, let me know: tell me what browser you’re using and what platform, please. You can report successes too, of course.

Here’s what I’ve found out so far:

Platform Browser Version Success?
Linux Amaya 8.2+ Yes
Linux Links 0.98 No
Linux Epiphany 1.0.6 Yes
Linux Konqueror 3.1.5 No
Linux Lynx 2.8.4rel.1 No
Linux Mozilla 1.5 Yes
Linux Mozilla Firebird 0.7 Yes
Linux (?) w3m 0.4.2 Yes
Mac OS X Camino ? Yes
Mac OS X IE ? NoDisplays “application/xsl+xml Identity transformation 2004-01-18 $Date: 2004/01/18 21:21:09 $ Copyright © 2004 Norman Walsh. All rights reserved. Perform the identity transformation; copy everything.” In other words, it seems to display the text of the file that is the target of the xml-stylesheet processing instruction. Very odd.
Mac OS X Mozilla ? Yes
Mac OS X Safari 1.1.1 Yes
Windows Amaya 8.1b Yes
Windows IE 5, 5.5, 6.0 No
Windows IE 6 (SP1) YesUnderstands “application/xml” but not “application/xhtml+xml” in the default configuration.
Windows Mozilla 1.4b, 1.6 Yes
Windows Opera 7.11, 7.50b1 Yes


Displays “application/xsl+xml Identity transformation 2004-01-18 $Date: 2004/01/18 21:21:09 $ Copyright © 2004 Norman Walsh. All rights reserved. Perform the identity transformation; copy everything.” In other words, it seems to display the text of the file that is the target of the xml-stylesheet processing instruction. Very odd.


Understands “application/xml” but not “application/xhtml+xml” in the default configuration.

Lessons Learned

I’ve changed a few things in response to feedback. I think these will be improvements: [Last update: 19 Jan 2004.]

  • The recommended MIME type for XHTML is “application/xhtml+xml”.

  • But some browsers (notably IE) handle “application/xml” better than “application/xhtml+xml”.

  • A little content-negotiation is probably in order. Beyond that, the MathML folks have clearly blazed a trail for us to follow. (Thanks, guys!)

  • Don’t put a document type declaration on the XHTML pages, because IE goes off and reads it (Good for you, IE! An actual feature not a bug!)

  • Remove   entities. This is actually imperative now that I’ve removed the document type declaration (because entities with no possibility of a declaration makes the document not well-formed).


I am just getting into this crazy xml stuff, but wanted to point out that safari 1.1.1 displays the application/xml page perfectly. Mac OS X 10.3, if that matters at all.


—Posted by Ryan Abrams on 19 Jan 2004 @ 04:00 UTC #

Safari works fine except for the calendar. The nbsp entities in the calendar are not being expanded.

—Posted by Stan Dyck Dyck on 19 Jan 2004 @ 05:53 UTC #

Konqueror 3.1.5 on Linux isn't able to cope with it. Pointing it to the URI of the application/xml launches an Save as/Open/Cancel dialog. Choosing 'Open' and Konqueror itself as the application, Konqueror says, "XML parsing error: fatal parsing error: the document is not in the correct file format in line 21, column 4." It points to the closing angle bracket of a <tr>.

Have you thought about also providing application/xhtml+xml, to see whether browsers react any different to that?

—Posted by Benja Fallenstein on 19 Jan 2004 @ 06:28 UTC #

Mozilla 1.4b (Win2k) - appears ok

IE6, SP1 (Win2k) - ok, except quotes wrong (probably local settings in error)

Mozilla 1.5 (Debian unstable) - ok

Epiphany 1.0.6 (Debian unstable) - ok

—Posted by Danny Ayers on 19 Jan 2004 @ 07:47 UTC #

"challenged" Hmph, just a friendly suggestion:-)

the application/xml one more or less works in IE6/windows2000 (actually I usually use text/xml, but I didn't dare suggest that given recent discussion of that on www-tag)

There is some encoding weirdnes (utf8 isn't being picked up automatically) which may be a problem with my setup.

But mainly I was going to comment on:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">

makes the file very slow to load, as IE really goes off and fetches the DTD.

This is a big overhead.

Mozilla based browsers don't normally fetch DTDs which speeds things up (but if they don't fetch them entities (including the nbsp) don't get defined. Actually mozilla never fetches dtds at the uri specified but "recognises" a few system and public ids and substitutes the dtd in its mozillahome/res directory.

(The page works fine on mozilla1.6/windows2000)

—Posted by David Carlisle on 19 Jan 2004 @ 09:00 UTC #

The application/xhtml+xml version renders perfectly in w3m/0.4.2!

—Posted by Silvestre Zabala on 19 Jan 2004 @ 11:31 UTC #

Windows Mozilla Firebird 0.7 Yes Windows 98 IE 5.0 No Windows ME IE 5.5 No Windows 98 Amaya 8.1b Yes

Amaya puts a rather large space between "text/html" and "version" in the link to the non-application/xml page. I can't see why unless it's just because it uses a bigger font for the <tt> text.

I like your lessons learned. May be the big lesson is: scrap DTDs completely. Perhaps there should be a simplified version of XML removing all the stuff nobody actually uses or uses properly in practice.

—Posted by Ed Davies on 19 Jan 2004 @ 12:08 UTC #

Two comments on your comment mechanism. The preview page showed "From: Ed" without my surname. Maybe that's where "Stan Dyck Dyck" came from on the text/html page's comments.

Also, in the previous comment, the preview showed each of the browsers on separate lines but the final version munged them into one line.

—Posted by Ed Savies on 19 Jan 2004 @ 12:13 UTC #

Win32 Opera 7.11: yes

Win32 Opera 7.50b1: yes

Win32 IE 6.0: no

—Posted by Ian Davis on 19 Jan 2004 @ 12:31 UTC #

Windows, Mozilla 1.4 looks just fine.

—Posted by Derek Dees on 19 Jan 2004 @ 01:17 UTC #

I'm running IE6 SP1 on Windows, and the application/xml version *doesn't* work. When I click on the link, I get the "File Download" dialog box. If I click the "Open" button on that box, I get a "file not found" error message. If I click "Save" and then double-click the saved file, I get an XML processing error (because IE can't find the associated XSL stylesheet).

But other people say they successfully opened the document with IE6 SP1. Are my settings somehow mangled?

—Posted by Seth Gordon on 19 Jan 2004 @ 03:48 UTC #

But other people say they successfully opened the document with IE6 SP1. Are my settings somehow mangled?

No. Norm moved the goalposts, changing the xml version from application/xml (which IE more or less understands) to application/xhtml+xml (which it doesn't, or at least doesn't by default, it may be possible to teach it new tricks?)

—Posted by David Carlisle on 19 Jan 2004 @ 11:19 UTC #

comment on your table

You have IE 6 sp 1 "yes" and IE6 "no" I'd expect them both to be yes for /xml and both to be no for /xhtml+xml

I guess IE on the mac is expecting an IE5-style wd-xsl namespaced stylesheet, and not seeing any templates in that namespace is just dumping the content as "literal result elements". That, and IE 5 and IE 5.5 on windows ,would probably work if you made your stylesheet valid for both xslt and the old microsoft dialect. You could rip the code out of which has this feature (stolen with permission from Jonathan Marsh) or of course you could use the whole of that stylesheet, then you could put some mathml in in your pages as well. There's currently a deplorable lack of mathematics on these pages you know:-)

—Posted by David Carlisle on 19 Jan 2004 @ 11:29 UTC #

David's right. I moved the goalposts. I shouldn't have done that. I'll republish with fixes tomorrow.

—Posted by Norman Walsh on 20 Jan 2004 @ 03:00 UTC #

Update on Konqueror 3.1.5 on Linux: application/xhtml+xml works fine.

However, I think that just means Konqi uses its HTML parser, not it's (apparently faulty?) XML parser.

—Posted by Benja Fallenstein on 20 Jan 2004 @ 02:39 UTC #