The default bug view has changed. See this FAQ.

scoped style sheets should allow scoped effects of @font-face and @keyframes

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
4 years ago
2 years ago

People

(Reporter: heycam, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
The HTML specification states that at-rules with global effects, such as @font-face and @keyframes, should have their effect scoped to the style scope.  Currently we just do not process these at-rules at all within scoped style sheets.
The HTML specification here is on crack, as far as dbaron and I can tell.  Certainly for @font-face....
Yep; we shouldn't implement this.  (I think we may have even discussed it in the CSS working group and agreed that HTML was wrong here.)
We should probably bring up the issue, though; I though I'd raised it before, but all I can find is https://www.w3.org/Bugs/Public/show_bug.cgi?id=15821
(Reporter)

Comment 4

4 years ago
Why is it that @font-face shouldn't be processed and declare fonts that only get resolved in font-family properties on elements within the scope?  It seems kind of reasonable to me.
Because font-family inherits, so the value on elements from within the scope can come from outside the scope, and usually does.
(Reporter)

Comment 6

4 years ago
But why is that bad?

Do you think that it's unreasonable for the meaning of a given font family name to change due to it being inherited into the scope?  Would it be OK if scoped style rules set font-family to that same name explicitly and had it resolve to the scoped @font-face?

To me, from an authoring PoV, it's straightforward to think of the font family names inheriting as names, and allowing the resolution of that to an actual font, which happens at the element, to be influenced by the scoped @font-face rule.
It's unreasonable because font-family names are done on a per-character basis.

So you'd end up in a situation where some characters used downloadable fonts and some did not depending on where in the fallback chain the family names fell and what the scoped style rules were...
I sent http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0251.html suggesting that the spec be changed to say @font-face and @keyframes should be ignored.
Blocks: 1018269

Comment 9

3 years ago
I don't know about @font-face, but ignoring @keyframes in scoped style-sheets basically means you can't use CSS animations without keyframes being declared separately in a global style-sheet(?) This seems very unintuitive to me.
We lost a few developer hours on this today not realizing that @keyframes did not work. Our use case in gaia is that we have several apps which use the same component. This component defines an animation, and because we don't have keyframes in scoped stylesheets, we have to have each app define the same keyframes as well. It's quite messy, so after using this a bit I would love to have @keyframes if possible.
(Reporter)

Comment 11

3 years ago
I still don't understand the concern in comment 7.

Regardless, the animation-name property isn't inherited, so you're much less likely to run up against the problem where a @keyframes name you write outside a style scope ends up being used, and re-defined, inside a style scope.
You need to log in before you can comment on or make changes to this bug.