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

[Ian Hickson]

On Wed, 23 May 2007, Julian Reschke wrote:
> > 
> > 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,

Where possible, this is required.


> and requiring content authors to send the proper mime types.

This is required by HTTP.


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

This is allowed.


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

HTML5 is that spec. That was the original goal of the WHATWG effort, and 
continues to be this goal. There are already other groups writing 
specifications that don't take today's content into account, e.g. XHTML2. 
Those specs will be ignored. I have no intention of writing a spec that 
will be ignored, it seems like a spectacular waste of time and of the 
human race's resources.


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

HTTP already makes this a MUST.


> - it disallows UAs to trust the mime type, as recommended by other specs,

Right, because otherwise the UA would fail to render giant swathes of 
existing content (literally billions of documents depend on this).


> - and finally it even requires UAs to ignore the HTTP status (which IMHO is
> even worse than the Content-Type issue).

Sadly, our opinions (and I agree with you that it is a bad thing) aren't 
really relevant here. It doesn't matter what we want, we have to take into 
account the existing content. Otherwise, browser vendors would ignore our 
spec, and we would have been reduced to creating fictional documents with 
no real world relevance.


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

Accepted by whom? The browser vendors are the main "clients" of this spec. 
Why would they not accept something that described what they had to do?

The _TAG findings_ are what haven't been accepted.


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

The ignoring of Content-Type is specific to certain parts of HTML, it's 
not a general thing. (Also, the HTTP working group has unfortunately been 
resistant to requests for changes that take reality into account; their 
spec may well end up irrelevant. There has been talk of making an "HTTP5" 
spec that fixes problems like this.)


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

That "different document" is the HTML5 spec. You are welcome to work on a 
document that describes what you would _like_ reality to have been. But it 
isn't this spec.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'