[whatwg] Why is @scoped required for <style> as flow content?
Jukka K. Korpela
jkorpela at cs.tut.fi
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
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
> 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
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:
> but can do this:
> 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,
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:
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
Content model for element body:
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.
More information about the whatwg