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

[Julian Reschke]

Ian Hickson wrote:
> 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.

Well, *always*, not most of the time.

>> and requiring content authors to send the proper mime types.
> 
> This is required by HTTP.

Yes, but by speccing that UAs will ignore it you weaken that 
requirement. That's why I would like to see that happening somewhere else.

Minimally, every time HTML5 requires recipients to ignore the content 
type, it should also remind content authors that they should supply a 
proper content type nevertheless.

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

Yes, but the WHATWG is not identical with the W3C HTML working group.

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

I don't think bringing XHTML2 into this discussion is useful. If it 
fails, there will be way more reasons.

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

If you require UAs to ignore the content type, please also remind 
authors that they need to send the correct type anyway. Otherwise you're 
*contributing* to the problem.

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

That may be true, but I think the author of software consuming HTML 
content should be able to make that decision.

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

Well, by requiring UAs to disrespect HTTP you contribute to the problem.

I have no problem with UAs *doing* that, I also have no problem with 
having a document that spells out what browsers do today to cope with 
broken content, but again, I think it's a very bad idea to put that 
stuff into a spec that obsoletes HTML4.

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

Accepted by the W3C.

> The _TAG findings_ are what haven't been accepted.

If you want to proceed with this activity inside the W3C, I think you 
really can't ignore what's been stated before. I don't see how HTML5 (as 
a W3C spec) can be incompatible with that TAG finding -- one or both 
will need to change.

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

1) There is not HTTP working group, only people interested to revive it, 
collecting open issues and potential resolutions.

2) I recall one instance where a WHATWG member requested a change in a 
mail to the former HTTP WG's mailing list, and as far as I can recall, 
he/she failed to get support for that (was it Content-Location?). 
Anyway, please provide a more precise pointer, or follow up on that 
mailing list.

3) As long as an "HTTP5" spec doesn't claim to be compatible with 
HTTP/1.1 (when it isn't), and that spec gets IETF/IESG support, fine.

>> 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, I understand that this is what the WHATWG'S HTML5 document does 
today; I just don't see how it can become the W3C's HTML5 spec while 
doing this. It seems to me it's pointless to continue this thread over 
here, but the same issues will come up again on the W3C mailing list for 
sure.

Best regards, Julian