This blog now uses Content Negotiation to serve the right content type for XHTML depending on the user agent. Now the pages are served as application/xhtml+xml for browsers that support it, like Mozilla Firefox. I have used m0n5t3r’s content negotiation plugin to do so. Otherwise this blog was serving the plain text/html which does not acknowledge the XML in the XHTML. In other words the XHTML part was not being used optimally. A small step towards more semantic and more XHTML way. As usual, I have done some testing and fixed some problems, but if you see any, do let me know.


March 12th, 2007 at 4:03 am
[...] blog recently started serving the right content type according to capability of the user agent (browser and so). Considering that I understand the [...]
March 12th, 2007 at 5:58 am
You seem to follow the q values, but in the event that both text/html and application/xhtml+xml have the same weight, you only serve application/xhtml+xml if the user agent specifically lists application/xhtml+xml in the Accept header (text/html if application/xhtml+xml is only covered by a wildcard). This does, however, mean that Konqueror and some other browsers that support the correct content type will still be served text/html.
So unless I’m mistaken, of all the major browsers, only Firefox and Opera are getting application/xhtml+xml (I don’t remember what Safari’s default Accept header is at the moment).
Interestingly, Mozilla’s developer site says that, despite the Accept header q value, it is usually best to send Firefox text/html since it doesn’t yet support incremental rendering of XML-parsed markup, and thus the page takes longer to display for Firefox users. Firefox 3 is supposed to have this fixed.
Opera still has a number of bugs with XHTML. In particular, it follows some of the HTML-specific provisions in CSS and DOM even when it parses the page as XML. Those provisions aren’t supposed to apply to XHTML when parsed as XML.
On the official Safari weblog, the developers said that HTML is the way to go unless you really *need* XML parsing, because Safari’s XHTML support isn’t as mature and well-tested yet.
Just some things to keep in mind.
March 12th, 2007 at 5:30 pm
Wow! David you have saved a lot of time in testing for me. Yes, as you said it does get served as
text/html. The wild card is not considered. I will try to fix the problem.Considering the bugs in Firefox and Opera, I think it really is a question of arriving at the tipping point from all perspectives. Unless us, the users, do not start giving it more importance, the developers will not too. There has to be a demand to fix these bugs.
Thanks a lot of the information, it has helped a lot.