Re: XHTML 1.0, section C14

Benjamin Hawkes-Lewis wrote:
> [...] 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.

If the content I'm serving is mathematically oriented and the 
*source* format for that content is XHTML+MathML how on earth am I 
supposed to convert that to HTML of equivalent quality? The best I 
can think is HTML+PNG images: user loses at least font scaling, 
baseline alignment and formula source. There's no point to use XHTML 
over HTML unless one is going to use some other XML based language 
so I consider this a meaningful example.

Note that if the user agent supports even basics of XHTML+MathML 
it's usually much better than a perfect HTML user agent in this use 
case.

Yes, this is only one example but I hope it illustrates the need for 
quality parameter. Only one variant can be the *source* format, all 
the other variants that the server is able to provide a more or less 
perfect approximations.

I'd ban the "*/*" in the Accept header unless it had a quality less 
than one. If the intent is to hint the server that UA is willing to 
download any binary file that choice should be considered a fallback 
and it's quality can never be 1. Or if UA's "download source 
variant" action has been triggered, then the UA shouldn't sent 
Accept header at all.

> 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.

Why? Imagine a perfect user agent that supports both XHTML and HTML 
without a flaw. Why should it prefer one over another? The server 
should send the *source* variant if it is able to provide any. (In 
the *best* case XHTML and HTML variants really are interchangeable 
and in that case it doesn't matter which variant the user agent gets).

IMHO, the UA should describe its support for various MIME types in 
its Accept header

> 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 agree. At least recommend that the *default* setup makes it 
immediately obvious that the content provider is sending invalid 
content. That way web "designers" cannot just ignore those errors 
and pretend that it hurts only a few.

-- 
Mikko

Received on Monday, 27 November 2006 12:27:05 UTC