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

[Ian Hickson]

On Thu, 24 May 2007, Julian Reschke wrote:
> >
> > (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 semantics of HTML are a key part of how user agents have to handle 
HTML. Having two separate documents isn't optimal either.


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

As I've said before, I'm no fan of these requirements either. But the only 
way I can see of making the "break HTTP" rules as narrow as possible is to 
have them be tied as closely to possible to the elements that require the 
rules to be broken. I don't think it would make sense for the HTTP spec to 
mention HTML elements -- it's better for specs to step on each other from 
above than from below, as it were.


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

Yes, that's what we're doing.


> So, if you don't care, why did you volunteer to edit that spec?

Because if I didn't, then we'd probably have two conflicting specs, and 
that would be confusing to a lot of people. And also, because it's just 
generally the Right Thing to do. It's just not absolutely required.


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

Likely, yes. I don't particularly expect it to change anything though. :-) 
After all, the HTML working group is also biased towards the browser 
vendors, to the point where the charter says the group should be 
reconsidered if the browser vendors pull out...


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

I have my hands full with HTML5 as it is. However, I'm on the HTTP mailing 
list, and would be happy to give support for anyone who wanted to champion 
pragmatic changes of this nature.

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