- From: andruud via GitHub <noreply@w3.org>
- Date: Wed, 12 Nov 2025 22:01:13 +0000
- To: public-css-archive@w3.org
> [@andruud](https://github.com/andruud) Do you think the `@namespace` option is better in that regard? It does not have the complexity of tree-scoping with all the cascading implications, as it can be polyfilled one-to-one with conventions/CSS Modules.
In short: yes. That looks like opt-in _lexical_ scoping, without being contaminated by the DOM-based scoping of `@scope`. That makes more sense.
For names defined by at-rules (e.g. `@keyframes`, `@function`, etc) that currently become _global_, this seems approachable. When dereferencing those names, we'd just traverse the lexical scope chain until we find a hit. By the way, we should have an anonymous version too, so you can have fully private stuff inside a mixin:
```css
@mixin --nice() {
@namespace {
@function --secret() {
result: tomato;
}
& {
background-color: --secret();
}
}
}
```
Although, we'll need to go through each at-rule one by one and think about what can be allowed. `@property`, for example, will not work, because we expect a given custom property `--foo` to have a single definition for the same element, they show up in JS enumerations, etc. We would have to _expose_ the prefix/scope, somehow.
For names _defined_ on the element level (custom properties), I don't think this proposal makes sense. I'd consider `@namespace --foo {}` as something that captures the names that would otherwise become global, and custom properties are already captured by the element they apply to. It also has the same problem as `@property`: a custom property, however private, still needs to ultimately exist on the computed style, and have some representation in CSSOM.
> > I'm fairly certain (tree-)scoped custom properties is off the table forever. It will likely cause unacceptable performance regressions.
>
> Is this true for the more simple namespacing approaches as well? If so, could you briefly point to what would be the performance bottleneck?
- If a custom property can no longer be identified on the _computed style_ of an element with just a simple name (string), I'd consider that pretty bad. (A tree-scoped name is a pair of [string, TreeScope], and I hate them.)
- If custom property lookup is slowed down when lexical scoping is _not_ involved, it's _very_ bad. (This is usually avoidable.)
I don't want to call it "simple", and I'm unenthusiastic about the idea that `@namespace --x` transforms "every ident" to lexically scoped idents. But if we do want to explore that direction, we don't necessarily have to give up in advance.
--
GitHub Notification of comment by andruud
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11798#issuecomment-3524095532 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 November 2025 22:01:13 UTC