On 5/23/07, Julian Reschke <[EMAIL PROTECTED]> wrote:
Ian Hickson wrote: > On Wed, 23 May 2007, Julian Reschke wrote: >>>>> http://lists.w3.org/Archives/Public/www-tag/2006Aug/0027.html >>>> Actually, I wasn't planning to. I think that that finding is a good >>>> one, and that we should work on making less content break it. >>> I recommend reading the first of the two links cited above. It >>> describes what I did to "work" on making less content break it, and >>> why I think that it's a lost cause. >> Actually, I read those messages when they were written. > > Ok, then you know that I have attempted to do the "work" you propose we > do. What more work can we do? For instance, continuing to allow UAs to trust the mime type, and requiring content authors to send the proper mime types. Or, allowing (opt-in) browsers to flag broken media types in the UI, as suggested in <http://lists.w3.org/Archives/Public/www-tag/2006Aug/0035.html > (yes, same thread). >> * I do understand that there's a gap between what the specs say >> Content-Type should do, and what works in reality. > > Indeed. And the specs, to be useful, have to match reality. That may be true if all we're discussing a spec that defines what a UA has to implement to be compatible with today's broken content. I absolutely agree that it's good to write that spec, but I disagree that this should be same spec as HTML5. >> * As we just saw with the XSLT example, making generalizations like in >> Anne's proposal is dangerous: for instance, Mozilla does check the >> content type of XSLT style sheets, and it seems people can live with >> that. In this particular case, XSLT content was served with type >> text/html, and when the problem was discovered, the author immediately >> fixed the server config. > > The HTML5 spec requires that Content-Type headers be obeyed everywhere > where I could possibly get away with requiring it. It only ignores it > where reality requires it. Let's look at an example. < http://www.whatwg.org/specs/web-apps/current-work/#the-img> currently states: "The remote server's response metadata (e.g. an HTTP 404 status code, or associated Content-Type headers) must be ignored when determining whether the resource obtained is a valid image or not. This allows servers to return images with error responses. User agents must not support non-image resources with the img element." Issues I have with this: - it doesn't provide tell content authors that the content-type header *should* reflect the mime type; instead it suggests it doesn't matter, - it disallows UAs to trust the mime type, as recommended by other specs, - and finally it even requires UAs to ignore the HTTP status (which IMHO is even worse than the Content-Type issue). >> * I think it would be bad if the W3C TAG finding on media types and a >> future W3C HTML spec would contradict each other. > > It would be worse if reality and the future HTML spec contradicted each > other. (It is already quite bad that the TAG finding contradicts reality.) Well, I disagree. The TAG finding says how things should work. If you think that this is wrong, you'll have to try to change *that* (I know you tried...), but just ignoring it in a W3C spec is unlikely to be accepted.
Can someone point out specifically how HTML5's section on error handling contradicts this TAG finding, especially sections 4 and 5? It says:
Web agents SHOULD have a configuration option that enables the display or logging of detected errors.
Obviously users don't want to see an alert every time an HTML page is served as text/plain, but if the UA logs that error or displays it plainly somewhere like Firefox's "Page Info" dialog, that should be enough. It also says:
An agent MUST NOT ignore or override authoritative metadata without the consent of the party employing the agent.
A UA could simply keep a preference in the UA's "advanced" options where this is enabled by default. It should be possible for a UA to satisfy both of those conditions and still do the content-type sniffing in HTML5. Also, HTML5 doesn't encourage authors to use incorrect content-type, it just suggests how browsers should handle errors.
(sorry I didn't hit "reply to all" the first time...) -- Jon Barnett
