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

Wed Jun 15 03:47:59 PDT 2011

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

Good point (though it's really "may cause" rather than "causes".)

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

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

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.

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

> 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. 
And there never was any particularly good reason to allow <style> in 
<head> only (but <script> both in <head> and <body>), and HTML5 is 
generally taking a more liberal attitude to the issue. The distinction 
between <head> and <body> is, after all, just a fairly artificial line.

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?

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

"Element style not allowed as child of element body in this context."

with the following explanation, which seems to say that it _is_ allowed:

"<style scoped>

Contexts in which element style may be used:
     If the scoped attribute is absent: where metadata content is expected.
     If the scoped attribute is absent: in a noscript element that is a 
child of a head element.
     If the scoped attribute is present: where flow content is expected, 
but before any other flow content other than other style elements and 
inter-element whitespace.
Content model for element body:
     Flow content."

Is this just a bug in the validator, or something deeper?

The validator has started issuing this message:

"The scoped attribute on the style element is not supported by browsers 
yet. It would probably be better to wait for implementations."

That's fine, though it doesn't describe the real risk explicitly (the 
style sheet will be applied globally). But it would be better if no such 
warnings were needed. If a new construct degrades gracefully (which 
means ignoring it, in this case), there's no particular reason to warn 
authors about implementation status.

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

 > And you can style the inside parts using<style scoped>.

Maybe some day. But it would still be unnatural to say <style scoped> 
when you want to make global style settings.

-- 
Yucca, http://www.cs.tut.fi/~jkorpela/