Closed Bug 830056 Opened 11 years ago Closed 7 years ago

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

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: heycam, Unassigned)

References

Details

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
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.
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.
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.
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.
May I suggest making an exception for inline styles added to the <head> element?

This would solve several existing scenarios where CSS animation is broken in FireFox:
- CSS packaged with WebPack and other bundlers
- Standalone .html files
- Client-side theming (i.e. based on user preferences) that haven't yet migrated to custom properties
Also, this issue seems to break SVGs with CSS animation that are referenced via a data URI. Couldn't an exception be made for all SVGs that declare animations (used in the SVG only) in an inline <style>?
Apologies, disregard comment #12. I was misinformed - these aren't all broken (must have misunderstood the FF known issue here: https://caniuse.com/#search=css%20animation).
This would have only scoped @font-face rules in <style scoped> elements, i.e. when you specifically opt in to scoping the <style> to that subtree.

But note that <style scoped> is in the process of being removed: bug 1345702.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.