W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] Why is @scoped required for <style> as flow content?

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 31 Jan 2012 00:11:24 +0000 (UTC)
Message-ID: <Pine.LNX.4.64.1201302342560.3868@ps20323.dreamhostps.com>
On Wed, 15 Jun 2011, Jukka K. Korpela wrote:
> 2011-06-15 3:26, Ian Hickson wrote:
> > 
> > Styling a whole document by having style sheets in the middle of the 
> > document causes flickering (as the browser updates the styles), and is 
> > hard to maintain. So we make this non-conforming, to help authors 
> > avoid these pitfalls. (Indeed, it's never been conforming, this is not 
> > new.)
> 
> If the intent is to help authors to avoid pitfalls, it would suffice to 
> give a warning (and explicitly mention the problem in the specification 
> or just explicitly define the meaning by saying that the time of 
> applying the style sheet is in this case browser-dependent).

That's what conformance errors are.


> > > There's a fundamental compatibility issue with<style scoped>. 
> > > Existing browsers simply ignore the scoped attribute and apply the 
> > > styles to the entire document. This is surely not what an author 
> > > means when he uses <style scoped> as per HTML5.
> > 
> > It's trivial to work around that using ID selectors in the interim.
> 
> I'm afraid few things if any are trivial when playing with selectors in 
> CSS. For one thing, ID selectors have drastic effect on specificity. 
> More fundamentally, if you want to use a piece of a document in another 
> and copy part or all of the original style sheet, it shouldn't be 
> necessary to modify the style sheet by throwing in ID selectors at 
> different places.

Sure, that's why we're adding the feature. The ID thing is just a 
temporary inconvenience while we are in the transition.


> The compatibility issue is rather serious when an author using a new 
> construct strictly the way it has been defined (and gets no complaint 
> from a validator) sees _all_ existing browsers do something global when 
> it was specifically defined to apply to a small part only.

In practice, authors test with browsers long before they test with a 
validator, so the validator part of this isn't really relevant.

Authors are generally quite familiar with the concept of graceful fallback 
and how to make things work in legacy UAs. I don't think there's any 
serious trouble here. There is a workaround that's trivial to implement, 
as described above.


> > > Suggestion: Drop<style scoped>. Instead, introduce a new attribute, 
> > > say styleref, which is permitted for elements that allow flow 
> > > content, or for any element (whichever is easier). The attribute 
> > > would specify a space-separated list of CSS stylesheet URLs, to be 
> > > applied inside the element.
> > 
> > That wouldn't solve the main use case: syndication. In that scenario, 
> > referencing external files is often a non-starter.
> 
> An external CSS file can do anything an embedded one can, but if the 
> pragmatic issue is that too many separate files would be needed, then we 
> could define a new media type for "scoped style sheet" and use
> 
> <style type="text/css-scoped">...</style>
> 
> Existing user agents would ignore the elements, which is probably better 
> than misapplying them (globally). Admittedly, this is somewhat hackish, 
> since media types and their parameters are supposed to describe the 
> data, not its usage, but this wouldn't be the first or worst deviation 
> from that principle.

Indeed. A scoped="" attribute does the same thing but better -- it can be 
made to work in legacy UAs, and doesn't do anything hackish with MIME 
types.


> > A system that cannot do this:
> > 
> >      <style></style>
> >     </head>
> >     <body>
> > 
> > but can do this:
> > 
> >     </head>
> >     <body>
> >      <style></style>
> > 
> > Seems artificially limited and really should just be fixed.
> 
> It's still a reality in which many people live, with no way to fix it.

Can you elaborate on which systems you are referring to?


> But unless I'm missing something, the current version allows the old 
> method of starting <body> with <style>, just provided that you write 
> <style scoped>. It would not matter whether browsers recognize the 
> attribute scoped or not, as the scope would be the entire document, 
> wouldn't it?

Sure.


> Well what _am_ I missing now, when testing with validator.w3.org, 
> <body><style scoped> causes this: [...]

Please file validator bugs with the validators.


> > If you can only affect some parts of the<body>, the site probably 
> > would also rather you didn't affect parts outside those parts by 
> > fiddling with them via CSS.
> 
> Maybe. Maybe nobody thought of it. Maybe it's just a limitation caused 
> by technicalities. Anyway, when I _can_ fiddle with presentation using 
> the style="..." attribute or with presentational markup, formally 
> disallowing <style> doesn't help anyone.

On the contrary, I think it makes maintenance a lot easier by pushing 
authors towards a better authoring style.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 30 January 2012 16:11:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC