W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2007

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

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 23 May 2007 09:18:37 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0705230912290.22702@dhalsim.dreamhost.com>
On Wed, 23 May 2007, Julian Reschke wrote:
> > > > 
> > > >    http://lists.w3.org/Archives/Public/www-tag/2006Aug/0027.html
> > >
> > > Actually, I wasn't planning to. I think that that finding is a good 
> > > one, and that we should work on making less content break it.
> > 
> > I recommend reading the first of the two links cited above. It 
> > describes what I did to "work" on making less content break it, and 
> > why I think that it's a lost cause.
> 
> Actually, I read those messages when they were written.

Ok, then you know that I have attempted to do the "work" you propose we 
do. What more work can we do?


> * I do understand that there's a gap between what the specs say 
> Content-Type should do, and what works in reality.

Indeed. And the specs, to be useful, have to match reality.


> * As we just saw with the XSLT example, making generalizations like in 
> Anne's proposal is dangerous: for instance, Mozilla does check the 
> content type of XSLT style sheets, and it seems people can live with 
> that. In this particular case, XSLT content was served with type 
> text/html, and when the problem was discovered, the author immediately 
> fixed the server config.

The HTML5 spec requires that Content-Type headers be obeyed everywhere 
where I could possibly get away with requiring it. It only ignores it 
where reality requires it.


> * I think it would be bad if the W3C TAG finding on media types and a 
> future W3C HTML spec would contradict each other.

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


> * I agree that it is a good thing to collect information about what UA 
> implementors need to do to be compatible with deployed content on the 
> web. On the other hand, I disagree that it's a good idea to include this 
> stuff as normative information into an HTML spec.

"Normative" means "what UA implementors need to do". Your statements, at 
least in the context of this work, iare self-contradictory. There's no 
point us making the spec be something that we know browser vendors have to 
ignore. We're not writing science fiction. We're writing a specification.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 23 May 2007 02:18:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:55 UTC