#659: CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.)
Discussions
2021-07-26
[is this a small delta?]
Lea: seems very reasonable to me, but not sure what the delta is.
Dan: I'm on it because Chris H pinged. If it is a small delta we want to move it quickly. But it looks like maybe it isn't a small delta. But not a CSS expert.
Tess: been a long time since I looked at this issue.
Peter: seems reasonable to me.. I've relied on things with @font-face propagating down ..
Tess: it's the right direction.. shadow tree gets to know about its context
Peter: nothing leaks upwards
Tess: I think i'ts good. Can't remember specifics from the discussion which happened over several years. A ton of gotchas. This is probably how it should work.
Peter: I agree
Sangwhan: prsumably CSS variables have scoping
Lea: they inherit down shadow trees - this was influenced by how variables behave.
Rossen: this looks pretty good
Peter: close this as satisfied?
Lea: I'm in favour of that. [writes closing comment]
Rossen: only thing I see - closing argument - don't recall we had resolution over email. Not a showstopper just an FYI. I have no evidence of an email resolution.
2021-07-26
Sangwhan: this is a long discussion for a small delta
Dan: but it is a reslolved change to CSS. Possibly not a small delta. Discuss at plenary where we have more CSS voices?
Sangwhan: don't think it's controversial..?
Dan: multi stakeholder? [leaves comment]
[punted to the plenary]
2021-08-23
Tess: my recollection - where it ended up - the purpose of the shadow dom is encapsulation - this design doesn't bring encapsulation. But intuitively matches.. ... it's what web developers who aren't familiar with programming languages expects - and what people familiar with lexically scoped languages expect. It's intuitive. Some slight oddities. But I'm happy with it. I see in the Moz standards position thread therw was some discussion. I can't say "great" before we get input from people familiar with implementation of CSS features and can look at it and say "this introduces a fundamental complexity" or something similar. I think the working group is getting this feedback. The right people are engaged. From an authoring perspective i think it's great.
Rossen: I agree with Tess regarding the authoring excpectations. It will enforce good practice. From an implementation PoV, it feels like we have 2 opposing efforts - 1 to encapsulate for performance benefits - 2 (this) the reverse look-up problem: as you find things in such a subtree then you have to go back and find it. Do we preemptively propogate properties and values down? That comes with some expense. Since it's "automatic" it will come at some cost for implementers and run-times. It's not all great.
Dan: what should we do? Wait?
Tess: I would be comfortable closing it as long as we said "We'd like to encourage the wg to solicit implementation complexity feedback from folks familiar with CSS implementation in browsers."
OpenedJul 23, 2021
Ya ya yawm TAG!
I'm requesting a TAG review of CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.).
It has been a long standing issue on how name-defining at-rules (@font-face etc.) should be handled across shadow tree boundaries. The existing behaviors either break shadow tree encapsulation, or do not allow such at-rules in shadow trees at all. They are non-interoperable between browsers, and even inconsistent in the same browser between different rules.
Following a recent CSSWG resolution, a new and reasonable behavior has been proposed. Chromium is planning to implement this new behavior, starting with the @counter-style rule. So I'm requesting a TAG review of this new spec.
Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @xiaochengh