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

Ian Hickson <ian@hixie.ch> wrote on 07/05/2008 07:22:54 PM:

> On Sat, 5 Jul 2008, Sam Ruby wrote:
> >
> > 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.
>
> The spec is not really the point here. The point is interoperability.
> Clearly if browsers don't do the same thing as each other, we don't have
> interoperability and one or more browsers have to change. The spec will
> just change to whatever the browsers decide on. It can help bring the
> browsers together, but that's about it.

I think that we are getting rather close to agreeing here.:

> > 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.
>
> Having things vary by browser fails to achieve the only goal here,
> interoperability. So there's only one workable solution.

Slight disagreement here: there are multiple potentially workable
solutions.  At best, the one captured by the current draft is but one of
them.

> > If any variation of the former is pursued, there is no fundamental
> > difference between sniffing for one given HTTP parameter vs another.
>
> I agree. So the key is to find a solution that can reach a steady state.
> The "I really mean it" parameter doesn't (since it will end up used on
> pages that aren't labelled correctly, and so other browsers won't support

> it as it would lead to them supporting fewer pages).

Any documented solution, including the one in the current draft, suffers
from the above.  Pages will be lagelled incorrectly.  Yes, even with the
rules captured by the current draft of HTML5.

To the extent that the HTML5 document limits itself to documenting
consistent error recovery for pages served incorrectly, then are few
issues.  If a page *can* be interpreted as text/plain (and in general, most
html pages and feeds can), then there is no reason that the consistent
error recovery couldn't provide *some* combination of parameters where the
sniffed type matches the official type.  In fact, I would go so far as to
say that making sure that this is always the case would be a worthy goal.

> The idea of having
> browsers converge on the common subset of what they already do to support

> the Web seems like the simplest way of reaching a steady state. That's
> what HTML5 is trying to do now.

Agreed.  But again, I will assert that there are multiple potential common
subsets.  Furthermore, I will assert that is is the fact that picking a
scheme that browsers are willing to converge to is a more important factor
than which subset is picked.

Another factor to consider is that the http working group is concerned with
more user agents than browsers.  Having the sniffed type not match the
official type for content that can be reasonably interpreted using the
official type is an issue; anything that can reduce the set of cases for
which this occurs would be a good thing.

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

- Sam Ruby