[whatwg] Why is @scoped required for <style> as flow content?
bzbarsky at MIT.EDU
Fri Mar 25 10:56:00 PDT 2011
On 3/25/11 12:53 PM, Nicholas Zakas wrote:
>>> The part of the spec that defines what browsers are supposed to do
> already reflects current browser behavior.
> Can you point me to that?
If the scoped attribute is present, then the user agent must
apply the specified style information only to the style element's
parent element (if any), and that element's child nodes. Otherwise,
the specified styles must, if applied, be applied to the entire
> And if the spec already specifies the current browser behavior, why does the definition of<style> require the scoped attribute in flow content?
> This seems very different than the improperly nested tags scenario
> you mention, where the parser needs to perform some error recovery.
It's really not that different, actually, from my point of view. In
both cases the page is doing something conceptually wrong (e.g. sticking
a stylesheet somewhere near the end of the document that affects the
whole document) and the spec is saying that this is not something we
want to consider ok.
We could argue about this of course; this is why I asked for use cases.
The use case of putting <style> without @scoped right at the start of
<body> is a good one, and I think that should be allowed...
> It just doesn't seem like requiring scoped at any point adds much value. It makes sense as an optional attribute, but I can't think of a reason why it should ever be required.
What the spec is requiring is that any global styles come in the <head>,
right? There are good reasons from a best-practice point of view for
doing that. That leaves two issues:
1) Whether validity is the right encouragement mechanism.
2) Whether there are good use cases that are NOT served by
<style @scoped> for <style> outside <head>.
So far we have one use case for #2 above, and it's one I agree the spec
More information about the whatwg