[whatwg] scoped style sheets and @-rules

[Tab Atkins Jr.]

On Mon, Jan 21, 2013 at 6:39 AM, L. David Baron <dbaron at dbaron.org> wrote:
> I thought I'd brought this issue up before, but I can't seem to find
> a record of it.
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-style-scoped
> currently says that, inside scoped style sheets, @page rules are
> ignored, but other @-rules are honored, scoped either to the style
> sheet or to the subtree.
>
> I think it makes perfect sense to honor @-rules whose effects are
> scoped to the style sheet (@namespace, also @charset if it weren't
> already ignored) or @-rules whose effects are to condition the rules
> inside of them (all the rules in css3-conditional: @media,
> @supports) or import more rules (@import).
>
> But I think it's a large amount of extra implementation complexity
> to honor @-rules whose purpose is to build global dictionaries (in
> particular, @keyframes and @font-face), and I suspect the end result
> of honoring them would yield technology that's more confusing for
> authors.  Anything that can be done by changing the meaning of an
> @keyframes or @font-face rule within a subtree could also be done by
> declaring a different animation rule or font-family within that
> subtree.  I suspect the extra clarity from the latter makes it a
> better authoring practice anyway, so I don't think implementations
> should be required to add support for a feature that it's better to
> not use.
>
> Thus I think the specification should mandate that @keyframes and
> @font-face are ignored in scoped style sheets, just like @page.
>
> I think it would also be good if the specification left the effects
> of unknown @-rules undefined until whether they should be supported
> can be properly considered.

Should we ignore them entirely, or just ignore the scoped-ness and
have them fill in the global dictionary?

I think it makes sense to be able to create @keyframes and @font-face
rules inside of a Component's style sheet, which is implicitly scoped,
for example.  Similar things (@counter-style, @text-transform, @image,
other imaginary things with similar effect) also make sense in the
same way.

However, I'd find it acceptable if authors had to make this explicit,
and put the rules inside of @host, which un-scopes its contained style
rules (or rather, transforms them from scope-contained to
scope-filtered).

(I plan to write the Scoped Styles spec in the next few weeks, so I
can define all of this there.)

~TJ