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 font-family name or an 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:
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
Scoping has this blanket statement that seems to require any name-defined thing to be 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:
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