- From: Daniel Dardailler <danield@w3.org>
- Date: Wed, 27 Jan 1999 13:02:47 +0100
- To: nir@nirdagan.com (Nir Dagan)
- cc: w3c-wai-gl@w3.org
> Content negotiation and the type attribute > are distinct topics. Distinct but related. If we keep them, I'd rather split the checkpoints along the line author's job/webmaster jobs. > I would say: > 1. Serve your documents with the correct Content-Type HTTP header. > Include a charset parameter whenever might be ambiguity the encoding. > [Priority 1] This is mixed as "serving" the document is a matter of server conf, while including a charset can be done in HTML. > 2. When refrering from an HTML document to a document with > a MIME type which is not natively undertood to many user agents, > specify the type attribute. > [Priority 3] Adding a type attribute to an A is just a more formal way to indicate the type of the target otherwise done thru the url file extension. I wonder how many agents use that and how useful it will prove to be in the field, compare to asking author to indicate the type of the resource inline, in the text, as in Click here for the <A HREF=foo.pdf>Foo spec in PDF (200K)</A>. Of course, both can be done. > The rationale for this is that this may save the user agent > work, and reduce internet traffic (I am not sure that this has > to do with accessibility). E.g., if the type of an OBJECT is > not supported by a browser it can avoid making an HTTP > request for it. Or save indexing robots retrieving documents > that they can't analize. They usually do a HEAD to get the content-type, losing a round-trip but not retrieving the entire document. > Content negotiation. > 3. If a resource is served in various formats or languages > use content negotiation to determine the format/language > preferred to the user. [priority 3] This is a webmaster job, or a combination of webmaster/author (adding a .conf file locally to indicate binding can be done by the author if the webmaster allows for it). > Also provide a "manual option" (e.g., a link) to switch from > one version to another. [priority 1] Yes, this is useful, and there is nothing in HTTP today that let you do that transparently. Saying it's a P1 now is a little too much I think. Overall, I question the accessibility relevance of all this, and I think it's more usability than anything else. We started with browser sniffing where some servers just reply "Go get a real browser" when they see lynx in the User Agent field, but we seem to have lost this track (I don't see any mention of that anymore). Even as P3, these sounds like very HTML/HTTP generic practices and I'm not sure we should pursue them.
Received on Wednesday, 27 January 1999 07:03:14 UTC