Re: [csswg-drafts] [css-scoping] Scoping of functions, other name-defining at-rules and custom idents (#11798)

The CSS Working Group just discussed `[css-scoping] Scoping of functions, other name-defining at-rules and custom idents`.

<details><summary>The full IRC log of that discussion</summary>
&lt;ydaniv> kizu: a lot of issue with naming, everything is mostly global<br>
&lt;ydaniv> ... not accessible to shadow DOM<br>
&lt;ydaniv> ... not handy for authors of libraries<br>
&lt;ydaniv> ... things clash together, different libraries and comps<br>
&lt;ydaniv> ... some tools have solutions, like PostCSS, nothing in CSS<br>
&lt;ydaniv> ... if you want to build a library you need to handle names yourself<br>
&lt;ydaniv> ... this is an issue about brainstorming about what can be done, like scoping<br>
&lt;ydaniv> ... if we do it with scoping it will be attached to trees, and this is not good for perfomance in some engines<br>
&lt;TabAtkins> q+<br>
&lt;ydaniv> ... maybe reuse the ... namespace<br>
&lt;ydaniv> ... have some namepsacing for anything nested<br>
&lt;lea> q+<br>
&lt;ydaniv> ... there was a question about being able to namespace some of the things<br>
&lt;ydaniv> ... maybe use ident() or other<br>
&lt;ydaniv> ... maybe expose it via CSSOM, or shadow roots<br>
&lt;ydaniv> TabAtkins: this looks good overall<br>
&lt;astearns> q+<br>
&lt;astearns> ack TabAtkins<br>
&lt;ydaniv> ... we need to see what things are scoped<br>
&lt;ydaniv> ... requires some reviews, but looks fine<br>
&lt;ydaniv> ... I think we'll allow namespaces,<br>
&lt;ydaniv> ... looks like a good approach<br>
&lt;lea> q?<br>
&lt;lea> q-<br>
&lt;lea> q+<br>
&lt;ydaniv> kizu: also anonymous namespace would be useful for small components if you don't want to share anything<br>
&lt;TabAtkins> s/allow namespaces/need to allow nested namespaces, which will require chaining the namespace component/<br>
&lt;ydaniv> astearns: I support this, but whatever we call it should probably not be "CSS modules"<br>
&lt;lea> q-<br>
&lt;ydaniv> ...  to not mistake it with other stuff<br>
&lt;astearns> ack astearns<br>
&lt;miriam> +1 to the idea<br>
&lt;ydaniv> fantasai: I support just "namespacing"<br>
&lt;lea> q+<br>
&lt;ydaniv> plinss: not happy with overloading @namespace<br>
&lt;emilio> q+<br>
&lt;ydaniv> ... we should define a new namespace, but concept is fine<br>
&lt;astearns> ack lea<br>
&lt;TabAtkins> @name-scope or something<br>
&lt;ydaniv> lea: are there impl. concerns currently?<br>
&lt;ydaniv> ... even tree scoping is not implemented<br>
&lt;astearns> +1 to some other @rule name<br>
&lt;ydaniv> ... when inheriting now values will change?<br>
&lt;ydaniv> TabAtkins: purely lexical thing<br>
&lt;ydaniv> ... things will bounce from the @-rule<br>
&lt;ydaniv> ... custom properties will not, but other things will have {missed}<br>
&lt;astearns> ack fantasai<br>
&lt;ydaniv> ... trying to avoid complexities of that<br>
&lt;ydaniv> fantasai: what if the spacing mechanism would work same as @namespace?<br>
&lt;lea> q+<br>
&lt;adamargyle> @realm? @prefix?<br>
&lt;ydaniv> plinss: my concern is that the original name was used for something else<br>
&lt;ydaniv> ... may not be used much anymore<br>
&lt;lea> q- (sorry)<br>
&lt;lea> q-<br>
&lt;ydaniv> fantasai: it's just binding of a name to a string<br>
&lt;ydaniv> TabAtkins: it is semantically related but substentialy different<br>
&lt;ydaniv> astearns: it would be good to have a new name that doesn't bump up against docs of the old @namespace<br>
&lt;ydaniv> ... would be good to have a new one even if hard<br>
&lt;astearns> ack emilio<br>
&lt;ydaniv> emilio: a bit of concern of how it interacts with custom properties<br>
&lt;ydaniv> ... you're parsing a value like @keyfarmes name, becomes an identifier<br>
&lt;ydaniv> ... if you specify from there it also get queued up<br>
&lt;ydaniv> ... but as soon as you do via custom properites, you lose context, like when you apply it<br>
&lt;ydaniv> ... I wonder how we'll do it in practice, I fear that recovering context will be hard<br>
&lt;ydaniv> ... have an example to show<br>
&lt;emilio> @namespace foo { @keyframes my-ident { ... } div { --custom: my-ident; animation-name: my-ident; /* works */; animation-name: var(--custom); /* ? */ }<br>
&lt;ydaniv> ... this is one of the things we'll need to figure out<br>
&lt;ydaniv> kizu: good thing think about<br>
&lt;ydaniv> ... if you define as property and not [missed]<br>
&lt;ydaniv> ... maybe we need somthing more explicit<br>
&lt;TabAtkins> Could have a function form of the scoped name *as well*, which is processed as substitution function, so eagerly even inside of custom props.<br>
&lt;ydaniv> ... for that namespace or another<br>
&lt;TabAtkins> `scoped-name(foo, my-ident)`<br>
&lt;ydaniv> ... maybhave somthing like a namespace function<br>
&lt;ydaniv> ... that says this is for this namespace or another<br>
&lt;ydaniv> astearns: so let's take that back to issue<br>
&lt;astearns> q?<br>
&lt;ydaniv> ... so we're looking for a resolution to start working on that, taking back to issue?<br>
&lt;ydaniv> kizu: yes<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11798#issuecomment-3524538444 using your GitHub account


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

Received on Thursday, 13 November 2025 00:37:09 UTC