[whatwg] Style sheet loading and parsing (over HTTP)
julian.reschke at gmx.de
Thu May 24 02:01:12 PDT 2007
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
>> 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.
> 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
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
More information about the whatwg