[whatwg] Style sheet loading and parsing (over HTTP)

[Jon Barnett]

On 5/23/07, Julian Reschke <julian.reschke at gmx.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070523/125469e5/attachment-0001.htm>