Re: Why Microsoft's authoritative=true won't work and is a bad idea

On Sat, 5 Jul 2008, Julian Reschke wrote:
> > 
> > This is exactly why this won't work. Sites will use this correctly, 
> > then someone will set some default somewhere incorrectly, or copy and 
> > paste a correct site somehow, or misunderstand a tutorial or 
> > something, and deploy it without testing in IE8. And it will work fine 
> > in all the browsers ...
> 
> Well, only if the other UAs do not adopt the proposal.

The only way you get get it to _not_ work in all the other browsers would 
be for all the browsers to be updated to support this simultaneously, with 
a simultaneous launch, and have the entire installed base upgraded at the 
same time. In practice, more than 25% of the install base still uses _IE6_ 
today. The amount of time between when a feature can first be used and 
when a feature cannot be copy-and-pasted by an ignorant author who isn't 
using the latest browsers is several _years_. That's plenty of time to 
poison the well and ruin the chances of the new feature getting deployed 
across all browsers.


> > The way out of this mess is containment. We define a strict set of 
> > Content-Type sniffing rules that are required to render the Web, and 
> > we get the browsers to converge on only sniffing for those. ...
> 
> So you can get the browser vendors to converge on a precise set of 
> sniffing rules, but you can't get them to agree on an opt-out?

The precise set is the set that is compatible with rendering the legacy 
content as expected, the minimal subset compatible with what browsers do. 
It can also be changed in response to browser feedback when it is 
discovered that it isn't quite perfect. It is far easier to incrementally 
move towards a set that is trying to be compatible with what the browsers 
already do than it is to get the browsers to jump to an extreme.


On Sat, 5 Jul 2008, Sam Ruby wrote:
> 
> Permit me to rephrase that in the form of a question, based on a live 
> example.  I just changed the content type of feed validator test cases 
> from "text/xml" to "text/plain; charset=utf-8".  I did this with the 
> following:
> 
> http://feedvalidator.googlecode.com/svn/trunk/feedvalidator/testcases/.htaccess
> 
> I then fetched the file using IE 7.0.5730.13, Firefox 3.0, Safari 3.1.2, 
> and Opera 9.50.  IE and Firefox rendered the content as a feed, Safari 
> as html, and Opera as text/plain.
>
> As I read the spec, content sniffing as defined by sections 2.7.2 (and 
> perhaps 2.7.3, despite the fact that my charset was sent as lower-case 
> utf-8 despite my specifying this parameter using upper case) specifies 
> that content served as "text/plain" effectively is an opt-out from 
> further content sniffing.
> 
> This leads to the question: what is the essential difference between 
> "text/plain" as defined by the spec and therefore is presumed to be 
> workable (despite all the evidence to the contrary), and 
> "authoritative=true" which is being rejected out of hand as unworkable.

text/plain might not be workable. If Opera and Safari find they have to 
change as well, then the spec will have to change too.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 5 July 2008 18:51:01 UTC