Research says that shows with X
in the name get higher ratings.
So... the issue of XHTML (and the fun of the application/xhtml+xml MIME-type) has once again risen to the surface.
An enterprising individual took it upon themselves to hunt down all personal web pages of so-called Alpha Geeks
that claim to be XHTML and subject them to various validation tests (which essentially tested the XHTML validity and that the page is being sent with the correct MIME-type).
Shocked I was to find that xiven.com was not mentioned in the list of fully XHTML compliant websites (which actually amounted to 1 site). Clearly I therefore do not merit Alpha Geek
status (I'm not sure whether to be pleased about that or not ☺). Also missed from the list was The Freaky Weblog and The LambCutlet Disorganization.
Meanwhile others are pondering how to correctly deal with browsers that don't accept application/xhtml+xml (yes, we mean Internet Explorer of course), given that the specification for XHTML media types states that under no circumstances should an XHTML1.1 document be sent with a text/html MIME-type. Well the answer of course can be found in this very weblog. If the browser doesn't support XHTML, send it HTML instead. In my case, the conversion from XHTML to HTML only takes a few simple regular expressions.
Further reading:
Posted: 2003-05-06 15:34:37 UTC by Xiven | Cross-references (1) | Comments (19)
Comments
Jacques Distler (2003-05-06 21:32:37 UTC)
"Meanwhile others are pondering how to correctly deal with browsers that don't accept application/xhtml+xml (yes, we mean Internet Explorer of course)..."
Actually, no, that's not the issue (or only part of the issue) I was dealing with. The issue is: will the browser barf when it encounters XHTML 1.1+MathML 2.0, served as application/xhtml+xml ? This is *not* the same as whether it can handle plain-old XHTML content served as application/xhtml+xml.
Camino (a Gecko-based browser), for instance, will cough up blood if I serve my blog to it as application/xhtml+xml. I don't care what its ACCEPT header says; it gets text/html.
Evan (2003-05-06 23:51:07 UTC)
Yes, as Jacques points out... when it comes to XHTML, down the rabbit hole we go...
May I just say that serving actual *HTML* to the non-compliant browsers, tags and everything, is going above and beyond the call of duty. Now that's REAL content negotiation.
Freaky (2003-05-07 04:02:18 UTC)
This reminded me I was going to make aagh.net serve HTML 4.01 to non-XHTML clients, so, er, I did :)
The relevent footer and alternate links are generated, and it even supports weights (will your code choose text/html with Accept: text/html, application/xhtml+xml;q=0.1?). ph33r XSLT ;)
Xiven (Registered) (2003-05-07 04:15:23 UTC)
"The issue is: will the browser barf when it encounters XHTML 1.1+MathML 2.0, served as application/xhtml+xml ?"
Interesting. I haven't really looked at MathML much. I guess I'll have to now. :)
"Camino (a Gecko-based browser), for instance, will cough up blood if I serve my blog to it as application/xhtml+xml. I don't care what its ACCEPT header says; it gets text/html."
I wasn't aware of that. Strange that a Gecko-based browser should fail in such a way. I'll admit I don't have much faith in the Accept header either though.
Xiven (Registered) (2003-05-07 04:25:00 UTC)
"This reminded me I was going to make aagh.net serve HTML 4.01 to non-XHTML clients, so, er, I did :)"
Excellent work :)
"ph33r XSLT ;)"
XSLT is another of those technologies on my list of things to learn.
Jon (2003-05-07 10:10:03 UTC)
True. But, what can I do if my Weblog host (blogspot) hasn't implemented application/xhtml + xml? If I had more control over my server, then I would do it.
Kamakaze (2003-05-07 10:34:36 UTC)
I find the best way to deal with this problem is to use HTML and send it as html/txt....
Freaky (2003-05-08 05:24:23 UTC)
Jon: There's no shame in using HTML 4.01. You even get to point and laugh at us for wasting our time for doing stuff like this for no apreciable benefit ;)
Jon Stanley (2003-05-08 09:49:37 UTC)
Hmm, I think I might go back to using HTML3.2. ;)
Or do everything in XML and use XSLT... and indeed I thought Xiven used XSLT, when it's just some RegExs. HTML browsers then get HTML, and XHTML browsers can get XHTML with correct MIME type.
As for XHTML + MathML, browsers shouldn't barf with that MIME type, since as per spec:
http://www.w3.org/TR/xhtml-media-types/#application-xhtml-xml
"XHTML Family document types suitable for this media type (application/xhtml+xml) include [XHTML1], [XHTMLBasic], [XHTML11] and [XHTML+MathML]."
However, Camino is based on a pretty old branch of Mozilla is it not? IIRC, 1.0.x...
Jacques Distler (2003-05-09 08:50:14 UTC)
To my knowledge, there is no browser in existence that follows the spec (while parsing XHTML, if you encounter an element from a namespace you don't understand, ignore it and just render the text) when served application/xhtml+xml.
Mozilla doesn't, Camino doesn't, Safari doesn't... Do you know of one which does?
Jonathan Porter (2003-05-09 16:10:54 UTC)
Since you spent all this energy on doing the right thing you should probably make two more slight changes. Both have to do with the HTTP headers. First since different user-agents get different content cache-control I believe should be "private". Secondly, you should probably add "Vary: Accept" to notify that user-agent on what headers you base your content-negotiation. All in all nice work I was hoping to have simlar functionaltiy whenever I put my own site up.
Jonathan Porter (2003-05-09 16:22:45 UTC)
In response to Jacques Distler I don't know about Safari, but Mozilla and I assume its derivates support application/xhtml+xml completely. If you go by the Accpet header its supports XHTML @ %100 and actually surpasses HTML (text/html) which is supported @ %90. Using XHTML+MathML DocTypes work flawlessly and if you have an SVG enabled build XHTML+SVG+MathML DocTypes work flawlessly (although the actual SVG implentation is rather incomplete at this point). Using the sample XHTML+SVG+MathML document @ the W3C with Mozilla works as expected.
Basil Crow (2003-05-09 16:48:48 UTC)
"In my case, the conversion from XHTML to HTML only takes a few simple regular expressions."
A few simple regular expressions . . . which you wouldn't mind sharing? :-)
Jacques Distler (2003-05-09 19:25:57 UTC)
*If* you have an SVG-enabled build, then XHTML+MathML+SVG works flawlessly.
But the Spec addresses the question of how a *non*-SVG-enabled build should perform when it encounters that doctype. AFAIK, Mozilla does not do what the spec says it should do, namely gracefully ignore the elements from the SVG namespace, and render the text.
Similarly, Camino is a non-MathML-enabled cousin of Mozilla. It *should* ignore elements from the MathML and SVG namespaces, and forge right on ahead.
Safari actually does *better* than Gecko-based browsers. It renders the page up to the first element from an unknown foreign namespace, and then poops out. Gecko-based browsers will not render anything unless they have specifically been built to support all of the namespaces used by the document.
James Graham (2003-05-10 15:01:28 UTC)
"Gecko-based browsers will not render anything unless they have specifically been built to support all of the namespaces used by the document."
At one point I tried putting some inline SVG on my home page, and non SVG mozilla builds coped fine. I was using the text/xml mime type at the time (which I think is allowed by the spec and seems reasonable for a mixed namespace document, even if application/xhtml+xml is better), which might have made a difference.
In addition, I know that Camino recently moved off a code branch and onto the trunk, so maybe it will be built with MathML support now. In any case, have you checked for the bug in bugzilla?
Jacques Distler (2003-05-10 18:50:59 UTC)
Did I file a bug?
http://bugzilla.mozilla.org/show_bug.cgi?id=190307
I've tried some recent Camino nightly builds. Still no dice.
I'm encouraged by your report that non-SVG-enabled Mozilla does not choke on SVG content.
I was not so successful in my experiment, but I probably screwed something up.
Mike Kozlowski (2003-05-19 17:38:20 UTC)
I'm shocked that you're not using XSLT to generate your page. I mean, I figured the only reason someone would go to the trouble of doing separate HTML and XHTML versions of a page would be because XSLT makes it so trivial to do that.
Tree21 (2003-05-30 00:14:09 UTC)
If the desire to do XHTML1.1 is for accessibility, why then doesnt the w3c give a clue about how to have links on a page for alternitive stylesheets? So far mine work in the text/html but not in application/xhtml+xml version (browser dependant) Finally got that straight with the php and guess I have to do the same with css, or hey just give up and migrate it all to XSLT? Clueless in Alaska
Treeagain (2003-05-30 00:43:09 UTC)
Sending XHTML as text/html is considered harmful should be prerequisite reading by w3c for XHTML authoring- "good read!"