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

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.

> ...
> 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?

> ...
>> 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).

> ...
>> 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.

> ...
>> 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? Besides, interoperability is not the single driving 
principle. Consistency with other standards and security should be 
considered as well.

> ...
> 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.

I would consider that a major issue, and would like to hear what the 
vendors actually have to say about it.

Best regards, Julian

Received on Friday, 24 August 2007 10:37:09 UTC