ifacethoughts

Using Content Negotiation

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.

Discussion [Participate or Link]

  1. XHTML: Technology Against Users on iface thoughts said:
    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 [...]

  2. David Hammond said:
    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.

  3. Abhijit Nadgouda said:
    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.

Say your thought!

Who are you?

If you want to use HTML you can use these tags: <a>, <em>, <strong>, <abbr>, <code>, <blockquote>. Closing the tags will be appreciated as this site uses valid XHTML.

freshthoughts

contactme

Abhijit Nadgouda
iface Consulting
India
+91 9819820312
Y!: anadgouda
GTalk: anadgouda@gmail.com
MSN: anadgouda@hotmail.com
Skype: anadgouda
My bookmarks

currentproject

Complete Wellbeing

badgesand...

This is the weblog of Abhijit Nadgouda where he writes down his thoughts on software development and related topics. You are invited to subscribe to the feed to stay updated or check out more subscription options. Or you can choose to browse by one of the topics.

Twitter - #mumbai - The city has started working today. The fears are still there, but the spirit will help in fighting it.