Re: review of content type rules by IETF/HTTP community

On Fri, 24 Aug 2007, Julian Reschke wrote:
> Ian Hickson wrote:
> > ...
> > >
> > > The solution is to require that compliant sniffing be combined with 
> > > compliant error reporting.  It is not a perfect solution, but it 
> > > will at least give us a chance to reintroduce feedback in the loop.
> > 
> > Telling the end user that the content is broken will not do anything.
> 
> But telling the content author may.

Well, we can check to see if this is the case. Firefox has been reporting 
errorneous Content-Type headers for stylesheets for years now. Has it had 
any effect?


> > Users wouldn't understand why the UA kept saying it, especially since 
> > it would say it for most pages on the Web. Making the errors only 
> > appear in error consoles is already done in many cases, and could be 
> > done in more, but that's a UA issue, not an interoperability issue, 
> > and thus out of scope for a specification. (Mozilla already reports 
> > Content-Type errors for stylesheets, but nobody cares.)
> 
> How do you know that nobody cares? What's the percentage of CSS served 
> with the wrong mime type?

I unfortunately don't have these stats handy. I think we would have to 
collect and examine these statistics before we really could discuss this 
further; without them we're both just guessing. (My guesses are based on 
what I remember of an earlier study along these lines, but I cannot recall 
who did that study nor can I find a reference to it.)

Philip provided some numbers in a sibling message on this thread.


> > > Why?  Users don't rely on that -- browser vendors do because they'd 
> > > rather whitewash errors than deal with questions.
> > 
> > What questions? Users aren't going to ask their browser vendor why the 
> > new version of their browser doesn't render the pages they visit 
> > correctly anymore -- they're just going to use another browser, which 
> > does.
> 
> Depends. If HTML5 has compelling new features, and all major vendors 
> actually do this, things may look differently. (I note that all major 
> vendors are part of this initiative).

Unfortunately this doesn't work -- existing browsers ("legacy" versions) 
count as "another browser" (IE6, e.g., still has the highest market 
share), even if all browser vendors simultaneously released new products 
with the feature you request. We can't use the carrot of new HTML5 
features to attract users, since authors won't use them widely until they 
are widely supported in the install base, and users won't upgrade if the 
new browser has a worse experience with existing pages than their old 
browsers.


> > > The reason for placing it in different specs is so that 
> > > implementations of HTML-generating applications would not have to 
> > > read it.  YMMV.
> > 
> > HTML-generating applications already don't have to read huge chunks of 
> > the spec. I don't think is a especially interesting section to 
> > extract.
> 
> And that's a problem that has been raised before. The current monolithic 
> structure negatively affects the readability for content producers. As 
> there are far more producers than consumers, I think this is the wrong 
> choice.

Yeah, we'll probably work on a stylesheet to hide some parts of the spec 
on request when the spec is more stable.


> > > I mean that it is missing:
> > > 
> > >   4.7.6  When sniffed type disagrees with Content-Type metadata
> > > 
> > >   If Content-Type metadata is present but differs from the sniffed
> > >   type, then this discrepancy SHOULD be reported to the user as a
> > >   content error unless such reporting has been turned off by
> > >   configuration.  [... perhaps also disable script handling within
> > >   the context of such a discrepancy ...]
> > 
> > Such user interface issues are out of scope of a specification, IMHO. 
> > They are not required for interoperability.
> 
> On the other hand, content sniffing is not required for compliant content,
> right?

Correct, but so what? It is required for interoperability.


> Besides, interoperability is not the single driving principle.

Interoperability is basically the only reason to have a spec.


> Consistency with other standards and security should be considered as 
> well.

I agree, security is paramount. That's why the HTML5 spec breaks 
interoperability in several cases for security reasons. This is only ever 
done after consultation with browser vendors, and is done as rarely as 
possible. In most of the cases, the browser vendors have already changed 
their implementations to match the changed spec. The only case I know of 
where this is blatently not the case is with the requirement that 
text/plain not ever be sniffed as text/html or as a feed, sadly.

In so far as consistency with other standards is concerned, that can be 
achieved in several ways -- one of the ways that we may wish to consider 
is to change the other standards. It makes no sense to have standards if 
the user agents don't follow them. I intend to make HTML5 implementable; 
if this requires breaking consistency with other standards that are 
themselves being implemented incorrectly, then so be it. Those standards 
are effectively useless anyway, and should be changed. (Yes, this includes 
HTTP, e.g. regarding Content-Location and Content-Type sniffing.)


> > Furthermore, that requirement would be ignored. If you can get a 
> > browser vendor to actually implement the above in a way you consider 
> > acceptable, then I'd consider putting it in the spec -- but there's no 
> > point putting something in which every single browser vendor has 
> > repeatedly told me and others that they would never do.
> > 
> > Browser vendors don't implement specs they disagree with. As spec 
> > authors, we only have power over user agent implementors so long as we 
> > tell them to do things they want to do anyway.
> 
> ...which would mean that we (== the HTML WG) have no power at all.

That's close to correct, yes. We only have as much power as the browser 
vendors and the Web designers grant us by deigning to listen to us. If we 
say something they don't like, they ignore us, and we become powerless. In 
some areas, we have a lot of leeway, because browser vendors may not care 
about the exact details of a solution. But if we stray outside their 
constraints -- e.g. if we require something that would change the 
rendering of many existing pages -- then they'll ignore us.

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

Received on Tuesday, 4 September 2007 22:48:35 UTC