<span class="gmail_quote"></span><div><div><span class="e" id="q_112b8e51cef5ebdd_0">On 5/23/07, <b class="gmail_sendername">Julian Reschke</b> <<a href="mailto:julian.reschke@gmx.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
julian.reschke@gmx.de</a>> wrote:</span></div><div><div><span class="e" id="q_112b8e51cef5ebdd_2"><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Ian Hickson wrote:<br>> On Wed, 23 May 2007, Julian Reschke wrote:<br>>>>>>    <a href="http://lists.w3.org/Archives/Public/www-tag/2006Aug/0027.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.w3.org/Archives/Public/www-tag/2006Aug/0027.html
</a><br>>>>> Actually, I wasn't planning to. I think that that finding is a good<br>>>>> one, and that we should work on making less content break it.<br>>>> I recommend reading the first of the two links cited above. It
<br>>>> describes what I did to "work" on making less content break it, and<br>>>> why I think that it's a lost cause.<br>>> Actually, I read those messages when they were written.<br>

><br>> Ok, then you know that I have attempted to do the "work" you propose we<br>> do. What more work can we do?<br><br>For instance, continuing to allow UAs to trust the mime type, and<br>requiring content authors to send the proper mime types.
<br><br>Or, allowing (opt-in) browsers to flag broken media types in the UI, as<br>suggested in<br><<a href="http://lists.w3.org/Archives/Public/www-tag/2006Aug/0035.html" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://lists.w3.org/Archives/Public/www-tag/2006Aug/0035.html
</a>> (yes,<br>same thread).<br><br>>> * I do understand that there's a gap between what the specs say<br>>> Content-Type should do, and what works in reality.<br>><br>> Indeed. And the specs, to be useful, have to match reality.
<br><br>That may be true if all we're discussing a spec that defines what a UA<br>has to implement to be compatible with today's broken content. I<br>absolutely agree that it's good to write that spec, but I disagree that
<br>this should be same spec as HTML5.<br><br>>> * As we just saw with the XSLT example, making generalizations like in<br>>> Anne's proposal is dangerous: for instance, Mozilla does check the<br>>> content type of XSLT style sheets, and it seems people can live with
<br>>> that. In this particular case, XSLT content was served with type<br>>> text/html, and when the problem was discovered, the author immediately<br>>> fixed the server config.<br>><br>> The HTML5 spec requires that Content-Type headers be obeyed everywhere
<br>> where I could possibly get away with requiring it. It only ignores it<br>> where reality requires it.<br><br>Let's look at an example.<br><<a href="http://www.whatwg.org/specs/web-apps/current-work/#the-img" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">

http://www.whatwg.org/specs/web-apps/current-work/#the-img</a>> currently<br>states:<br><br>"The remote server's response metadata (e.g. an HTTP 404 status code, or<br>associated Content-Type headers) must be ignored when determining
<br>whether the resource obtained is a valid image or not.<br><br>This allows servers to return images with error responses.<br><br>User agents must not support non-image resources with the img element."<br><br>Issues I have with this:
<br><br>- it doesn't provide tell content authors that the content-type header<br>*should* reflect the mime type; instead it suggests it doesn't matter,<br><br>- it disallows UAs to trust the mime type, as recommended by other specs,
<br><br>- and finally it even requires UAs to ignore the HTTP status (which IMHO<br>is even worse than the Content-Type issue).<br><br>>> * I think it would be bad if the W3C TAG finding on media types and a<br>>> future W3C HTML spec would contradict each other.
<br>><br>> It would be worse if reality and the future HTML spec contradicted each<br>> other. (It is already quite bad that the TAG finding contradicts reality.)<br><br>Well, I disagree. The TAG finding says how things should work.
<br><br>If you think that this is wrong, you'll have to try to change *that* (I<br>know you tried...), but just ignoring it in a W3C spec is unlikely to be<br>accepted.</blockquote></span></div><div><br>Can someone point out specifically how HTML5's section on error handling contradicts this TAG finding, especially sections 4 and 5?
<br><br>It says:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">Web agents SHOULD have a configuration option that
enables the display or logging of detected errors.<br></blockquote></div><br><div>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.
<br><br>It also says:<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">An agent MUST NOT ignore or override authoritative
metadata without the consent of the party employing the agent.</blockquote><div><br>A UA could simply keep a preference in the UA's "advanced" options where this is enabled by default.  <br></div><br>It should be possible for a UA to satisfy both of those conditions and still do the content-type sniffing in HTML5.
<br><br>Also, HTML5 doesn't encourage authors to use incorrect content-type, it just suggests how browsers should handle errors.<br></div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

</blockquote></div><br>(sorry I didn't hit "reply to all" the first time...)<br clear="all"><br>-- <br>Jon Barnett