Well, Mozilla 1.6 renders both pages perfectly.

I have for quite some time served all my pages as application/xhtml+xml for browsers that claim to support this (currently only Mozilla, AFAICS), and this works very well.

It's easy to do this, using the content negotiation feature in Apache, as documented on this page: "http://www.christian-web-masters.com/articles/web_XHTML.html" (though I believe I found the technique first on this German page: "http://schneegans.de/tips/apache-xhtml/").

Minor entity problem in Safari 1.1.1: The   entities in the calendar on the right appear as-is (ie not resolved to a non-breaking space).

(BTW I support your draconian stand)

Interesting. In that previous comment I typed ampersand-n-b-s-p-semicolon, and when I clicked "preview comment", it showed up like that in the preview. But it also resolved it into an actual non-breaking space in the comment, which I didn't notice. And now it's still there.

(Hmm, there may be a way to break well-formedness of your document here...)

Hey Norm,

This one worked fine under Windows Mozilla 1.5 and Firebird 0.7. Opera 6.01 displayed all the text and links for the application/xml one but ignored the CSS stylesheet; Opera did use the stylesheet with the text/html one. Opera is up to 7.23 now, so it would be interesting to see if that version has the same problem with your app/xml version.

This page http://www.w3.org/TR/xhtml-media-types/ (I'd be happy to use an HTML anchor here :) says:

"'application/xhtml+xml' SHOULD be used for XHTML Family documents, and the use of 'text/html' SHOULD be limited to HTML-compatible XHTML 1.0 documents."

Also see http://www.w3.org/TR/xhtml-media-types/#summary and http://www.w3.org/TR/xhtml1/#guidelines

To report, the article works transparently in Konqueror 3.1.4. With the exception of subtle font issues (grrr, someday I *will* figure out fonts under Linux), the page looks almost identical under Opera 7.23. Not only that, but Opera provides that really nice navigation system if you provide the <link rel="next" ... /> and the like.

The blurred line between interpreting and presenting HTML and correctly processing xhtml is rather interesting:

"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!)" - Norman Walsh, article body

Doesn't this beg for catalog support in those browsers that are actually going to resolve identifiers? I would think that as we ask, more and more, for our web browsers to be XML readers that they should be able to take advantage of resources like XML catalogs. As a user, I am quite curious to know what my various browsers do behind the scenes, but sometimes that documentation can be sparse on this front.

Mozilla 1.6 (my regular browser) displays this fine. IE6 fails, putting up a dialog that says "Internet Explorer cannot download application application-xml from norman.walsh.name. Internet Explorer was not able to open this internet site. The requested site is either unavailable or could not be found. Please try again later."

Jim

OK, IE6 SP1 is showing this, but it thinks the encoding is "Western European" (rather than UTF-8), so the curly apostrophe shows up as "a-with-caret euro-sign trademark-sign". And then when I clicked the talkback button, the page for submitting the talkback *is* recognized as UTF-8.

Hi Norm,

this works just great in Mozilla Firebird 0.7 on Solaris 9. FWIW, I strongly support your "draconian" approach as well.

Cheers,

--Scott