Re: HTML5 vs content type sniffing

> On Sat, 26 Jan 2008, Frank Ellermann wrote:
>>
>> Robert Siemer wrote:
>>
>>> That's the best: html5 rules over what "text/plain" really means.
>>
>> While they're at it...  overrule CHARMOD, replace IANA by a Wiki  
>> page,
>> use an undocumented URL scheme, silently deprecate XHTML, claim that
>> breaking backwards compatibility everywhere is about IE bugs, etc.

 From http://ln.hixie.ch/?start=1144794177&count=1
"Unfortunately, we're now at a stage where browsers are continuously  
having to reverse-engineer each other to determine why they are  
handling content differently. A browser can't afford to render any  
less content than a browser with more market share, because otherwise  
users won't switch, and the new browser will not be adopted."

By that argument, browsers with largest market share would profit  
from changing their content sniffing rules continously. Hmm, somthing  
is missing here...

I think a better description would be that browsers continously try  
to adapt to new/faulty server configurations. This is a process that  
will go on as long as the internet evolves. And it is not under  
control of browser makers. HTML5 special rules for "+xml" content  
types had no need 5 years ago and who knows what will be needed next?  
Tackling this process from the "we define what browser currently do  
as standard" seems to be a strange approach.

In the case of "text/plain" apache httpd is still (2.2.6) shipping  
with DefaultType set to it, ignoring the rules set up by RFC 2616  
(which seem to be unchanged in httpbis as far as i can see). So, if  
the apache defaults are changed, will whatwg have to change the  
sniffing "standard"? most likely.

//Stefan

--
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

Received on Tuesday, 29 January 2008 10:54:07 UTC