- From: andruud <notifications@github.com>
- Date: Thu, 10 Apr 2025 03:32:56 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/1031/2792299253@github.com>
andruud left a comment (w3ctag/design-reviews#1031) 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](https://drafts.csswg.org/css-mixins-1/#typedef-dashed-function), and more generally [arbitrary substitution functions](https://drafts.csswg.org/css-values-5/#arbitrary-substitution-function), 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_. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/1031#issuecomment-2792299253 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/1031/2792299253@github.com>
Received on Thursday, 10 April 2025 10:33:00 UTC