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

Ian Hickson wrote:
> On Wed, 23 May 2007, Julian Reschke wrote:
>>>> 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.
> 
> That might work. I'll try to keep that in mind.

Great.

> ...
> That may be the case, but you are e-mailing the WHATWG here, not the HTML 
> working group.
> 
> (In point of fact, however, I would imagine that if the HTML working group 
> didn't work on a spec that told the user agents what to do, the browser 
> vendors would be likely to leave the HTML working group. I personally am 
> only interested in editing the spec that says what the user agents must 
> do, as it's the only spec with relevance in the real world. If the spec 
> I'm working on isn't that spec, then I'll stop working on it, and return 
> to working on the spec with real-world relevance.)

But that's exactly the UA-centric nature of the WHATWG specs that I 
don't like (and I don't think I'm alone). A spec that spends 75% of it's 
space to specify error recovery for UAs is IMHO not the optimal place to 
specify the semantics of HTML.

> ...
> The entire point of specifications is to remove decisions like that from 
> the implementors. :-)

Sometimes, but I don't think it's the case here.

A MUST level requirement to ignore the content-type forces an 
implementor to either break RFC2616 or HTML5. Am I the only one who 
thinks that the "all-specification-decisions-belong-to-us" philosophy is 
problematic, when it affects other parts of the protocol stack?

>>>> 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.
> 
> I don't particularly care if the W3C accepts or doesn't accept the HTML5 
> spec. They're not the ones who have to implement the spec, or who will 
> decide how successful the specification is. It's the browser vendors who 
> have that role.

Yes, but I thought the "plan" was to take HTML5 and take it through the 
W3C process? So, if you don't care, why did you volunteer to edit that spec?

>>> 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.
> 
> I'm happy for the TAG finding to change. The HTML5 spec can't change, 
> since it is constrained by the large amount of existing content.

That discussion will take place on the W3C HTML mailing list then.

> ...
>> 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.
> 
> Content-Location is the prime example I was thinking of, yes.

The mailing list thread is at 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2006OctDec/thread.html#msg190>. 
  I don't think it was discussed to the end, but on the other hand I 
also don't see any kind of consensus to make a change. Maybe you should 
restart it then.

>...

Best regards, Julian

Received on Thursday, 24 May 2007 02:01:12 UTC