- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Wed, 22 Nov 2006 00:38:32 +0000
- To: "Jukka K. Korpela" <jkorpela@cs.tut.fi>
- Cc: www-html@w3.org
On Tue, 2006-11-21 at 21:13 +0200, Jukka K. Korpela wrote: > The current techniques for browser sniffing, based on rejecting the > information that IE sends in Accept headers and trying to recognize > the _browser_ might work in the hands of educated authors, but they > are surely not something that should be recommended to authors in > general. To get down to specifics, servers should not be sniffing for Internet Explorer in particular: both because Internet Explorer is frequently spoofed and because the problem of deceptive Accept headers is not limited to IE. Instead, servers should either: 1) Only serve application/xhtml+xml to user agents whose Accept header prefers it over text/html /and/ includes the type (note /not/ the string) application/xhtml+xml explicitly in the header. 2) Only serve application/xhtml+xml to user agents whose Accept header explicitly or implicitly prefers it over text/html. I increasingly lean towards solution 2 because it allows Internet Explorer the option of expressing its incompetence with a header such as: > text/html,*/*;0.999 or (better): > */*,application/xhtml+xml;0.001 Developers should remain cautious, given that no browsers handle XHTML as well as they handle HTML 4.01 Strict, except for the sample browser that comes with the Flying Saucer library and which only handles XHTML: https://xhtmlrenderer.dev.java.net/r6/faq.html#id4 Of course, this in itself shouldn't deter developers from using XHTML, since most browsers are so terrible at handling HTML that the difference may not be particularly significant. Unfortunately, working out which requests want which sorts of content is actually the easy problem. The hard problem, which desperately needs work, is standardizing methodologies for transforming content between the brave new world of XML-based markup and the old world of text/html and image/gif -- and building those standardized methodologies into content management systems, web frameworks, and blogging software. Without this, the chasm of backwards compatibility will forever block our road into the future.
Received on Wednesday, 22 November 2006 01:00:19 UTC