Re: XHTML 1.0, section C14

On Sat, 25 Nov 2006, Shane McCarron wrote:
> Let's all roll over and keep using 1997 technology and hacking around 
> using weird-ass abstraction libraries to implement "Web 2.0" (gag-me)
> on top of incompatible underlying implementations [...] In my world I 
> always personally ignore */* in the accept header.

Then on Sun, 2006-11-26 at 00:24 +0000, Ian Hickson wrote: 
> Assuming the first part of the above is supposed to be sarcastic and
> the second part is not, I'm confused. You're condemning people for not
> following the standards ("incompatible underlying implementations")
> while simultaneously admitting to doing the same yourself?
> 
> Standards compliance begins at home.

As far as I can tell, this charge isn't quite fair. At the risk of
repeating myself, the HTTP 1.1 specification allows Shane to interpret
the Accept header any way she chooses. Re-read the section on
server-driven content negotiation: in order to its improve it's "best
guess", "an origin server is not limited to these dimensions [the
Accept-* headers and the User Agent header] and MAY vary the response
based on any aspect of the request, including information outside the
request-header fields or within extension header fields not defined by
this specification."

http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.1

I for one will continue to try and get both browsers and servers to
improve their content negotiation; but we will be fighting a losing
battle so long as a web specifications fail to make requisite behaviours
a compliance issue. For example, web standards could specify that:

1) Servers ABSOLUTELY MUST not serve application/xhtml+xml to user
agents that do not prefer application/xhtml+xml over text/html,
explicitly or implicitly.

2) User agents ABSOLUTELY MUST prefer either application/xhtml+xml or
text/html over the other. (Yes, that means the W3C validator too!) I've
already suggested means to bring most old user agents into line.

3) User agents ABSOLUTELY MUST warn users (even if such a warning can be
configured to be only a threatening beep or icon in the status bar) when
interpreting content served with one MIME type as though it were served
with another, based on MIME type sniffing. (I realize, Ian, that you've
tried pretty hard to get user agents to behave better in this regard;
but I do not think W3C has exerted all its latent might yet.
Interestingly, the Gnome Nautilus file manager seems to do something
like this and in a pretty user-hostile fashion too, so it's not
completely impossible in a client-facing system.)

I preface my MUSTs with ABSOLUTELY, because the IETF definition of MUST
makes it pretty weak (and SHOULD is virtually indistinguishable from
MAY, which implementors read as DON'T BOTHER TO). Things that are
required for the system to work MUST be absolute compliance requirements
too. T1) and 2) may be hacks, but they are necessary hacks. We could
also look again at creating an HTTP 1.2 if we care to put things on a
fresh footing, maybe picking up from:

http://www.w3.org/TR/WD-http-pep.html

--
Benjamin Hawkes-Lewis

Received on Monday, 27 November 2006 10:30:29 UTC