W3C home > Mailing lists > Public > www-html@w3.org > November 2006

Re: XHTML 1.0, section C14

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
Message-Id: <1164155912.24407.209.camel@galahad>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:08 GMT