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

[Julian Reschke]

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.


>> * I agree that it is a good thing to collect information about what UA 
>> implementors need to do to be compatible with deployed content on the 
>> web. On the other hand, I disagree that it's a good idea to include this 
>> stuff as normative information into an HTML spec.
> 
> "Normative" means "what UA implementors need to do". Your statements, at 
> least in the context of this work, iare self-contradictory. There's no 
> point us making the spec be something that we know browser vendors have to 
> ignore. We're not writing science fiction. We're writing a specification.

What I'm saying is that an HTML spec should be silent on these issues, 
instead of contradicting the other specs that are relevant. If you don't 
like what these specs say, try to revise them. But don't try to redefine 
these things in HTML5.

Again, that doesn't mean that documenting what's needed today isn't a 
good thing. I just think it needs to be a different document.

Best regards, Julian