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

[Ian Hickson]

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.


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

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


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

My point was just that I have no intention of writing a spec that will be 
ignored, since that seems like a spectacular waste of time and of the 
human race's resources.


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

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


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


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

Also, note that personally I don't have much of a stake in whether the 
spec is a W3C spec or not. While I think it would be nice for the W3C to 
continue its role in the development of the Web, I don't think it is 
critical. We have shown that it is quite possible to write the HTML 
specification outside the W3C, and have it be successful.


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

That sounds like a working group to me. :-)


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


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

The idea would be to make it compatible with the existing content and user 
agents. Compatibility with a specification which doesn't match reality is 
not especially useful. (This is academic, however. I don't think anyone 
has any plans for writing an HTTP5 yet.)


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

I urge you to raise this with the HTML working group then. This thread is 
currently in the WHATWG mailing list, which the HTML working group 
chairmen don't follow.

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