[whatwg] scoped style sheets and @-rules

[L. David Baron]

On Sunday 2013-02-17 11:35 -0600, Glenn Maynard wrote:
> On Mon, Jan 21, 2013 at 8:39 AM, L. David Baron <dbaron at dbaron.org> wrote:
> 
> > 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.
> >
> 
> You could make the same argument against most of @scoped: you don't need to
> define a scoped style for a class, just use a different class name.

I think for the rest of @scoped, there are both significant
performance and encapsulation advantages.

> It seems more likely that you'd want to use this for font-faces or
> keyframes so that you can be sure the name won't collide.  For example, a
> templating system might output
> 
> <div>
>     <style scoped>
>     @font-face { font-family: "font"; src: url("font.ttf"); }
>     </style>
>     <span style="font-family: font;">content</span>
> </div>
> 
> where the font URL is dynamically generated and the span is entered by the
> user, who's been told that the font-family "font" will be defined to
> something.  The template doesn't need to worry about colliding with a
> font-family by that name elsewhere (including other instances of the same
> template or elsewhere in the document).
> 
> I don't know about implementation complexity (though I don't know why
> creating a stack of font-face dictionaries would be any more complex than
> creating a stack of style rules), but I don't think this is any more
> complex for authors than the rest of @scoped.

One of the big problems with @font-face is that it's not obvious
whether the @font-face rules should be scoped to:

  1. font-family declarations in the scoped style sheet, or

  2. elements in the style sheet's scope, whether the declarations
     came from the scoped style sheet or not

(The HTML spec currently says (2), but I think used to say (1).)

Option (1) adds a huge amount of implementation complexity; it
requires the CSS cascading process, at least for font-family, to
carry around information about where the declarations came from.

Option (2) is more reasonably implementable, but I'm not sure it's
what authors expect.  In particular, it implies changes to fonts
that are inherited in from outside the scoped style sheet.  It's not
clear to me that this behavior is useful enough to authors to be
worth the (still not insubstantial) work of implementing it.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂