On Sat, 5 Jul 2008, Sam Ruby wrote:
> > >
> > > There are only two workable solutions. [a and b]
> >
> > [b] fails to achieve the only goal here, interoperability. So there's
> > only one workable solution.
>
> Slight disagreement here: there are multiple potentially workable
> solutions.
You said there were two, I pointed out why one of those two isn't a
solution, and now there are multiple? I'm confused.
> > 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.
I think you are missing the key difference here.
With what the spec says, which is the status quo plus or minus the delta
between implementations, we have already run through the people making the
mistakes and have already gotten to a pretty stable steady state. Getting
from here to a state where all the browsers do the same thing is a small
change.
With a radical new parameter, we are much further from the status quo, and
so it would take significantly more to get to a steady state. Furthermore,
since the new parameter is in fact identical in semantic meaning to the
origin Content-Type header, there's not really any reason to believe that
that final steady state wouldn't look exactly like today's near-steady
state (except more complicated, since it would have more inputs).
> 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.
I agree, and indeed currently HTML5 says to honour text/plain in all cases
where the content is valid text/plain content. Personally I think it's a
security risk to treat text/plain as anything but.
> Another factor to consider is that the http working group is concerned
> with more user agents than browsers.
I should hope everyone is. However, that doesn't change anything -- it's
still the same ecosystem, and the same content. We don't want tools
treating content different than each other, whether they are Web browsers
or not.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'