Re: [w3ctag/design-reviews] Request for review: CSS tree-scoped at-rule names and references (for @font-face, @keyframes, etc.) (#659)

This is being requested for TAG feedback because it is a CSS-wide behavior change (well, behavior *definition*), and interacts with shadows and their information-hiding/componentization.

The examples Xiaocheng cites are indeed a great in-depth explanation of the behavior, but in short, the behavior is:

* Whenever a property references an at-rule by name, the keyword for the name is a "tree-scoped reference", and remembers what tree its stylesheet is in. When it needs to find the referenced at-rule, it looks in that tree specifically, even if it's been inherited or assigned to elements deeper in nested shadows.

 This ensures that components can't accidentally clash with at-rules defined outside of themselves, unintentionally changing the meaning of inherited or ::part()-inserted values. (Without this, a well-behaved component would have to give their at-rules UUID-ish names to have a high likelihood of avoiding clashes.)

* If a tree-scoped reference can't find the named at-rule in its remembered tree, it walks *up* the tree-of-trees to find the name in an ancestor scope. (Or, put another way, at-rules "inherit" down into shadows.)

 This mimics the implicit information-leakage that CSS already purposely allows with property inheritance, particularly inheritance of custom properties. It also means that a page can use in-house components that reference things like @font-faces it knows will exist in the outer document. Accidental clashes can only occur if a component is expecting this "inheritance" to work, but is nested inside of a foreign component that also uses the same name; this is the exact same failure scenario that custom properties have.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/659#issuecomment-885942848