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

Ian Hickson wrote on 07/05/2008 02:50:23 PM:
>
> 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.

At the present time, four browsers give three different answers, one of
which matches the spec.  Changing the spec can't improve upon this
situation.

There are only two workable solutions.  One is to declare that this
combination of value for _official_ type and parameters and pattern
detected in the content itself maps to a specific _sniffed type_, which
would require at least two browsers to change.  Another is to declare that
this combination is undefined, and thereby may vary based on the browser.

If any variation of the former is pursued, there is no fundamental
difference between sniffing for one given HTTP parameter vs another.

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

- Sam Ruby