[csswg-drafts] [css-scoping-1] Spec for tree-scoped names need more nuance (#13305)

andruud has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-scoping-1] Spec for tree-scoped names need more nuance ==
Scoping has this blanket statement that seems to _require_ any name-defined thing to be a tree-scoped name:

> If an at-rule or property defines a name that other CSS constructs can refer to it by, such as a [@font-face](https://drafts.csswg.org/css-fonts-5/#at-font-face-rule) [font-family](https://drafts.csswg.org/css-fonts-4/#descdef-font-face-font-family) name or an [anchor-scope](https://drafts.csswg.org/css-anchor-position-1/#propdef-anchor-scope) name, it **MUST** be defined as a tree-scoped name.

This used to be a good guideline for how to define new features. If New Feature has author-defined names, they are tree-scoped names. End of story.

The problem is that we keep _ignoring_ this:

 - Timeline names are not tree-scoped, https://github.com/w3c/csswg-drafts/issues/8135.
 - Container names are not tree-scoped (anymore), https://github.com/w3c/csswg-drafts/issues/12090.

Making these exceptions seriously harms the legitimacy of the tree-scoping concept, and makes it more unclear how new features should be defined. (They should apparently not necessarily follow what css-scoping-1 says.)

Basically, my question is: is there a way to _explain_ why timeline/container names are not tree-scoped when e.g. anchor names are? Ideally in a way which can automatically apply to new features? cc @tabatkins

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13305 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 7 January 2026 12:37:00 UTC