There has been some CSS WG discussion around dropping using and just using the local context where the function is used, yet this explainer still includes it. Is it not removed or is the explainer outdated?

It's likely the explainer is out of date - although I'm not sure there were any resolutions or decisions, only some conversation in the github threads.

I think it's reasonable to keep using in the explainer until https://github.com/w3c/csswg-drafts/issues/10954 is resolved.

The discussion in that issue does seem to converge on using being dropped, though.

I think it's reasonable to keep using in the explainer until w3c/csswg-drafts#10954 is resolved.

The discussion in that issue does seem to converge on using being dropped, though.

It seems like it's going to resolve imminently, so could you ping us when it resolves so we could review then?

Yes, will do.

@LeaVerou It's now resolved, and the spec has been updated.

@andruud Awesome. I’m no longer in the TAG (my term expired a few days ago), but my advice to the current TAG is that this is sorely needed functionality for authors, and there are no architectural issues with it.

Hi @andruud, the TAG discussed it but didn't reach consensus. Feedbacks:

1. Regarding privacy and security:
   1. Thank you for responding to the security & privacy questionnaire. In response to the question about "do you have a security & privacy" section, you've said "not yet". We'd like to encourage you to write that, even if it is minimal.
   2. We suggest thinking about any possible security & privacy implications - especially if the proposal could increase potential for CSS-based fingerprinting or CSS injection.
   3. If the answer to these questions is "no", it's still worth documenting.
   4. If the answer is "maybe," then please specify mitigations.
2. Regarding the explainer:
   1. We prefer the explainer to be put next to the relevant spec (like this one) instead of in a personal repo
   2. The explainer could be made clearer. It currently includes both functions and mixins, which is confusing, and the mixins part seems incomplete (though it's out of the scope of this review)
3. An interesting question: have you considered naming it "Custom Macros"? Since the entire CSS custom variable mechanism is built on top of token substitution, which is how macros work. This is even more explicit with @function

1. The spec has had privacy and security sections for quite some time already, although it was indeed missing at the time this issue was filed. We have thought about this, without finding any issues. I'll bring it up for discussion internally again, though.
2. Yes, the explainer intentionally includes mixins because it's relevant for understanding the greater problem space. So perhaps it was incorrect to consider mixins fully out of scope for this review.
3. I see what you mean. To my knowledge, this is the first time it has been proposed. "Macro" can mean different things depending on your background, though: in C/C++, it's a preprocessor thing that can substitute anything, at any level (<dashed-function>s, and more generally arbitrary substitution functions, can not: they only exist in the value space); LISP macros work differently, and are more integrated with the language; and MS Excel Macros are something else entirely. At least to me, it's not obvious that the term "macro" would meaningfully help the author in understanding what's going on; "CSS macros" would likely be subtly different from any existing definition of "macro". Of course "CSS functions" has the same problem, but my point is that "macro" isn't an obvious improvement.

Hi @andruud, the TAG discussed the feature and are satisfied with it.

We would also like to see the explainer improved, as it seems to mostly serve early exploration purposes and are mixed with the mixins feature. The TAG prefers a dedicated explainer that's put next to the relevant spec, which is not only for TAG reviews, but also serves as an official explainer for everyone who reads the spec.