- From: Etienne Miret <elimerl@gmail.com>
- Date: Mon, 21 Apr 2008 17:32:09 +0200
- To: Dean Edridge <dean@55.co.nz>
- CC: David Dorward <david@dorward.me.uk>, www-validator@w3.org, Alexandre Alapetite <alexandre@alapetite.net>
Hi Dean, I'm pretty much agree with David on those points. Dean Edridge a écrit : > Hi, > > Here's the problem with the W3C Validator as I see it. > > The W3C Validator does not send an Accept header by default. > IMHO it is not good practise for any web server to send XHTML to a > user-agent without first knowing that the user-agent accepts XHTML. This > may seem like an odd concept to some but it is just the way things are > if you want to use XHTML on the web today. In some situations you may > get away with sending XHTML to everyone, but such situations are rare. I > myself, will not send XHTML to a user-agent that does not specifically > declare that it accepts application/xhtml+xml. I think we have a real-world versus standards issue here. Standard-compliant content-negotiation requires you to understand the lack of "Accept" header as "The user-agent accepts anything", hence, you should send XHTML to such user-agent. However, in the real-world some UA won't send a correct accept header, and those UA are typically unable to handle XHTML, so you *need* hacks. There is no way around it. You need some dirty hack if you want to support IE. I don't think however, that the hack should be in the W3C validator (which is precisely about standard compliance) rather than in the Web server. > When they could actually just do this if the validator had an accept > header. > <?php > if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml")) > { > $mime = "application/xhtml+xml"; > } > else > { > $mime = "text/html"; > } > header("Content-Type: $mime; charset=utf-8"); > ?> As I said, you don't apply correct content-negotiation here. Although this might be a good thing to do in the real world, you cannot complain if it raises issues with a tools that's precisely about respecting standards. > Part a) Have the W3C Validator send, by default, an appropriate Accept > header with all the media types that it supports. This could look > something like this: > Accept: application/xhtml+xml, application/xml; q=0.5, text/html; q=9, > text/xml, application/smil, application/smil+xml, image/svg+xml; q=0.3, > ;*/* q=0.1 I feel this is a good idea. At least, it would do no harm. The issue with the current lack of Accept header is not that it means the validator doesn't understand XHTML, it is that it means the validator can handle plain text, PDF or MS Word documents. Since IE7 sends an Accept header which includes "application/msword" (with the maximum quality value), doing content-negotiation between a Word and an HTML document is not purely theoretical. I don't know if some websites do it, but it sure is possible. I had once an issue, when - for test purpose - I added a plain text variant to my home page. Well, for several months the validator just wouldn't validate my home page. I solved the issue by telling my Web server that in case several variants where acceptable and none preferred by the UA, it should send first the XHTML one, then the HTML one, and the plain text one only as a last resort. In that case it was easy, but when doing content-negotiation between an MS Word and an HTML document, setting the MS Word document as the preferred one is - well - realistic. But of course, as soon as you do content-negotiation, you are likely to be willing to test different variants. In that case you need an option to set the accept header rather than a default value. In my case, I had plain text, HTML and XHTML. The fact that by default the validator would check the plain text variant was a annoying, but usually I used a specific URL in order to check the HTML or the XHTML variant. > Part b) Have an ability for users/webdevelopers to add their own > media-types that would override the default Accept settings that would > normally be sent by the validator. This is explained above, but I feel > that it is only beneficial to maintainers of the website being validated > or other tech like people, so I do not think this would be a total > solution on it's own. I think that being able to specify a custom header will only be useful to tech like people anyway (well, you need to know what content-negotiation is). But being such a person, I would much more appreciate to do it in the GUI than by editing the request URL. So, I agree with the two additions you're asking for, but I want to stress the fact that people who want to use XHTML and to support IE will still have to do some dirty hacks. Regards, -- Etienne Miret Ne m'envoyez pas de fichier Word SVP, je ne peux pas les lire ! Don't send me Word attachments please, I can't read them! http://perso.ens-lyon.fr/etienne.miret/Netiquette/no_MS_Office
Received on Monday, 21 April 2008 15:32:49 UTC