And why it is somehow important. And I am going to explain it using a part of the current version of the XHTML2 object element. You are still there? I would like to thank the W3C mailings list subscribers for providing this information (I hope it is correct :-)). Consider the following two uses of the object element (I left out the quality value, since I think it is not important in this matter):
<object type="application/xhtml+xml" data="index"> <object type="text/html" data="index"/> </object>
<object type="application/xhtml+xml,text/html" data="index"/>
The second one is obviously XHTML2.0, since the type attribute in XHTML1.x can't accept multiple arguments. But what is the difference?
The first one is the one you can compare with this piece of PHP:
if(stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")){
$mime = "application/xhtml+xml";
}else{
$mime = "text/html";
}
So if it is supported, it will get it. Browsers like Opera 7.2, which only supports the application/xhtml+xml content-type partially (check the previous post's comments). It doesn't support scripting, will take that page. With the second object element, the one from XHTML2.0 it will actually see it has choices and won't take application/xhtml+xml, since it knows it has better support for text/html.
Despiteall above, I still think it is stupid to put a technology in you accept header that you don't fully support... Well actually, nothing is supported correctly, Opera has a point there!
(BTW, does anyone has a proper PHP-script (or CGI/.htaccess) for handling the quality values?)
I have updated the article on serving XHTML to include respect for quality values. It is adapted from a technique used by Bill Mason. It probably needs a bit of testing, but at the moment it is correctly serving XHTML to Gecko browsers, and HTML to IE6 and Opera 7, the latter being because of the q rating.
AFAIK the only serious bug in Opera's application/xhtml+xml handling is scripting. So, do we still have to respect the quality value, when we are writing XHTML Basic?
It really depends on your point of view. We can adopt two different stances:
application/xhtml+xml when the Accept header includes it, irrespective of quality ratingThe problem with the latter approach is that some user agents may have the string in their Accept header, but with a quality rating of zero, to specifically exclude that MIME type. Why would the agent do this? It seems foolish to me, but then I'm not a software developer.
Obviously Opera Software feel that their product does a better job of handling text/html, so they have set their header to reflect this, retaining the ability to handle application/xhtml+xml when needed. I think this represents a loss for Opera users, but I feel disinclined to browser-sniff just for their benefit. You will notice that I removed the detection of the W3C validator from the article as well. That is a move on my part to avoid browser sniffing, although the technique can easily be adapted to include it if necessary.
As far as XHTML Basic is concerned, I don't envisage authoring with it anytime in the near future; however, I would still be inclined to respect the quality rating.
Now I understand what this Q-talk was all about :)
I think you should respect what the browser-creator thinks the browser can handle best. Sending application/xhtml+xml to browsers which prefer text/html is the same as using a fixed font-size in your CSS 'cause that looks better.