- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 21:38:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Proposal: Custom CSS Functions & Mixins`, and agreed to the following:
* `RESOLVED: Start ED of css-mixins for CSS Custom Functions and Mixins`
<details><summary>The full IRC log of that discussion</summary>
<miriam> https://css.oddbird.net/sasslike/mixins-functions/<br>
<fantasai> miriam: explainer linked from issue<br>
<fantasai> miriam: a lot of interest in mixins and functions, which have existed in preprocessors for a long time<br>
<fantasai> miriam: these are two separate features that have syntax overlap and use-case overlap<br>
<fantasai> miriam: they are both ways of wrapping up some CSS logic and repeating it in various places<br>
<fantasai> miriam: Both have a name and take parameters, do some logic, and output some CSS<br>
<fantasai> miriam: difference is that mixins exist in the declaration space, outputting entire declarations or even rule blocks<br>
<fantasai> miriam: and functions exist in the value space, simlar to existing functions<br>
<fantasai> miriam: Functions exist in CSS, custom functions would be a way for authors to define their own functions in a declarative way<br>
<fantasai> miriam: would be limited in some ways to what you can do declaratively<br>
<fantasai> miriam: takes what you can do e.g. in complex set of calcs, and grouping with a nicer syntax<br>
<fantasai> miriam: mixins are a newere concept in CSS, but same idea at a declaration level, returning entire blocks<br>
<fantasai> miriam: a lot of discussion in issue around syntax and details of execution<br>
<fantasai> miriam: mixed interst in functions and mixins<br>
<fantasai> miriam: question to group is, do we want to take any of this up on the standards track<br>
<florian> q+<br>
<emilio> q+<br>
<fantasai> miriam: and if so where would we work on it?<br>
<astearns> ack florian<br>
<fantasai> florian: When we introduced CSS Variables, what was esepcially interesting was that the way they worked gave us powers you couldn't achieve in a preprocessor<br>
<fantasai> florian: do you gain abilities in native CSS that you couldn't do in preprocessor?<br>
<fantasai> miriam: You would be able to reference CSS conditions<br>
<fantasai> miriam: preprocessor could also output conditions, so maybe not all that different?<br>
<fantasai> florian: like a media query?<br>
<fantasai> miriam: No, actually, main thing you get here is passing in a custom property<br>
<fantasai> miriam: couldn't be able to do that in preprocessor<br>
<astearns> ack emilio<br>
<fantasai> TabAtkins: could maybe do that in preprocessor, but could get explosive in length<br>
<fantasai> emilio: Clearly interesting for authors, but some questions<br>
<fantasai> emilio: for mixins, when does the substitution happen?<br>
<fantasai> emilio: e.g. applying to nested rules sounds fancy, but if you expand it after parsing then it becomes crazy complicated<br>
<fantasai> emilio: how does that interact with cascade<br>
<fantasai> emilio: if expanding during selector matching, then [missed]<br>
<fantasai> emilio: I'm wondering if we know the answers to these questions?<br>
<fantasai> emilio: So how much have these details been thought througH/<br>
<fantasai> miriam: some looking into those questions. Anders has been playing around with ideas. No fixed proposals.<br>
<fantasai> TabAtkins: idea is that mixins expand essentially at parse-time, but not relying on matching because that would be weird<br>
<fantasai> TabAtkins: hopefully desugar into nesting<br>
<fantasai> TabAtkins: functions theoretically desugar into inlining everything<br>
<fantasai> TabAtkins: just some amount of variable scoping<br>
<fantasai> TabAtkins: so idea right now is that mixins should resolve very early, parse-ish time<br>
<fantasai> emilio: If you pass a variable in mixin, then reference..?<br>
<fantasai> TabAtkins: You need to [...]<br>
<Nicole> q+<br>
<astearns> ack Nicole<br>
<TabAtkins> s/.../uniquify the variable name so the ref can stick around to runtime/<br>
<florian> q+<br>
<fantasai> Nicole: Seems like something we should talk about<br>
<fantasai> TabAtkins: any objection to starting a draft?<br>
<fantasai> astearns: single draft, multiple drafts?<br>
<fantasai> TabAtkins: mixins probably fit best in cascade, functions in variables, but since they share a lot of concepts maybe their own module<br>
<fantasai> miriam: they're both kindof like a macros<br>
<fantasai> s/macros/macro<br>
<fantasai> matthieud: Putting them together might make things more confused.<br>
<fantasai> [discussion of functions vs macros and macros that are functions]<br>
<TabAtkins> LISP-4-EVA<br>
<fantasai> miriam: Each would have a name-defining at-rule, and they would share defining parameters.<br>
<fantasai> miriam: so might make sense to have in a shared space<br>
<fantasai> astearns: Could work on them together in ED, and then decide whether to split out at FPWD<br>
<chrishtr> +1 to a new draft<br>
<astearns> ack florian<br>
<fantasai> <fantasai> +1 to that approach<br>
<kbabbitt> q+<br>
<fantasai> florian: We used to say CSS doesn't have functions, but functional notations that look like functions.<br>
<fantasai> florian: but a bunch of them actually are functions, e.g. trig functions<br>
<astearns> ack kbabbitt<br>
<fantasai> florian: this goes further in that direction, but we already crossed the bridget<br>
<fantasai> kbabbitt: So question of timing impacts CSSOM<br>
<florian> s/the bridget/the bridge already<br>
<fantasai> kbabbitt: if I walk through a stylesheet now, 1:1<br>
<fantasai> kbabbitt: like C macros<br>
<fantasai> kbabbitt: if I change how they expand, does that change the CSSOM, would that cause breakage?<br>
<fantasai> TabAtkins: functions would get preserved in OM<br>
<florian> s/look like functions./look like functions, but are just convenient syntactic groupings, without any particular notion of returning anything/<br>
<fantasai> TabAtkins: wrt mixins, could expand or not<br>
<fantasai> TabAtkins: but need to not be depending on run-time behavior<br>
<fremy> q?<br>
<fremy> q+<br>
<astearns> ack fremy<br>
<fantasai> fremy: Something I'm missing from the explainer, if we assume that mixins are something that you can simulate and do the replacement<br>
<fantasai> fremy: would be good to have an example of what it will actually look like<br>
<fantasai> fremy: I have a lot of questions better answered by examples<br>
<fantasai> fremy: That's a request for next revision, a clear example of this is what author writes, and this is how it gets "compiled"<br>
<TabAtkins> yeah, that's very doable<br>
<fantasai> astearns: any other questions/concerns about starting this work?<br>
<fantasai> astearns: proposed resolution to start an Editors Draft on mixins and functions, with Miriam and Tab editing<br>
<chrishtr> q+<br>
<chrishtr> custom add-ins<br>
<fremy> or just mixins?<br>
<fantasai> [bikeshedding spec names]<br>
<bkardell_> css-fun<br>
<fremy> @bkardell lol :)<br>
<fantasai> emilio: css-cpp, for css pre-processor<br>
<fantasai> css-custom, css-custom-functions-and-mixins, css-custom-functions<br>
<kbabbitt> css-fun-mix ?<br>
<florian> css-macros<br>
<fremy> css-mixins +1<br>
<fantasai> astearns: proposes css-mixins as the shortname<br>
<fantasai> PROPOSED: Start ED of css-mixins for CSS Custom Functions and Mixins<br>
<fantasai> RESOLVED: Start ED of css-mixins for CSS Custom Functions and Mixins<br>
<astearns> ack chrishtr<br>
<fantasai> chrishtr: Does anyone have initial feedback on miriam's syntax proposal?<br>
<emilio> q+<br>
<fremy> +1, I think @miriam did a great job "distilling" all the feedback in a common ground<br>
<fantasai> astearns: Suggest we take what's in the issue as a starting point, and people can file specific issues on specific concerns or suggestion<br>
<astearns> ack emilio<br>
<fantasai> emilio: syntax seems fine offhand, but maybe we need some other function, depending on how mixins end up working<br>
<fantasai> emilio: we may need to differentiate actual variables to mixin arguments<br>
<fantasai> emilio: in the mixin example in the explainer, there's e.g. background: var(--space). But could be a variable set on the element<br>
<fantasai> emilio: so var inside mixins vs external variables<br>
<fantasai> emilio: I think if we differentiate argument vs external variables<br>
<fantasai> TabAtkins: same discussion as for function<br>
<fantasai> TabAtkins: my preference is lexical variables, you only get those that are specifically forwarded to you.<br>
<fantasai> TabAtkins: those exist and nothing else does<br>
<fantasai> TabAtkins: keeps a simpler model, you know names you have access to<br>
<fantasai> TabAtkins: and makes JS-backed functions/mixins work without having to pass the entire style to the function<br>
<fantasai> miriam: That's been the most active part of the discussion lately, would be great to extract into its own issue<br>
<fantasai> emilio: I would see it as a nice feature, to use external variables<br>
<fantasai> emilio: if you want JS-backed, then yeah you need to specify dependencies somehow, because JS can do whatever<br>
<fantasai> <fantasai> +1 to emilio<br>
<fantasai> fremy: I think this discussion is one of the questions I had<br>
<fantasai> fremy: proposal makes sense in one way, but do we use a var() function as part of the arguments then when does var() get replaced?<br>
<fantasai> fremy: as an author if you use var(--background) you want the var [missed this]<br>
<fantasai> fremy: and not get mixed up<br>
<fantasai> emilio: I think Tab's proposal, you would replace the variable with another variable reference<br>
<fremy> --function(var(--x))<br>
<fantasai> emilio: as you pass it in<br>
<fantasai> TabAtkins: JS-backed mixin would have typedOM concept of unresolved variable to manipulate<br>
<fremy> var(--x) is from the element<br>
<fantasai> TabAtkins: but functions could give a real value<br>
<fremy> but for a mixin, that's less clear<br>
<fantasai> TabAtkins: I would prevent lexical and dynamic scope<br>
<fremy> so I would prefer arg(--x) vs var(--x) even if var(--x) is not allowed in the function otherwise<br>
<fantasai> emilio: I think specifying dependencies explicitly is good, even if you don't do JS stuff.<br>
<florian> q?<br>
<astearns> ack fantasai<br>
<emilio> fantasai: you could do the var substitution in various way<br>
<emilio> ... only locally defined vars / params<br>
<emilio> ... first local, then global<br>
<emilio> ... you could have var() and arg()<br>
<fremy> q+<br>
<emilio> ... I think they're worth exploring<br>
<florian> q+<br>
<emilio> ... I think I tend to agree that being able to pull the variables without passing them in makes sense<br>
<emilio> ... to avoid passing them over and over<br>
<fantasai> emilio: I think Tab's proposal would declare the variables you want in the function definition, not to have to call them in<br>
<astearns> ack fremy<br>
<fantasai> s/call them in/pass them every time at the call site/<br>
<fantasai> fremy: It still remains a question, if you say var() is replaced, especially for mixins, you can't replace var() before<br>
<emilio> fremy: if you see var() is replace, specially for mixins you cannot replace var() before<br>
<fantasai> emilio: I think you can substitute them eagerly, just not by the resolved value<br>
<fantasai> emilio: you would subsitute with the variable reference<br>
<fantasai> emilio: e.g. if the arg us --foo, gets passed var(--radius) then you'd replace var(--foo) with var(--radius)<br>
<fantasai> fremy: then if you have another variable --radius it would get mixed up<br>
<fantasai> emilio: no at that stage, all your references are unresolved element variable references, no function variable references<br>
<fantasai> emilio: I think this works<br>
<astearns> ack florian<br>
<fantasai> florian: ...<br>
<fantasai> florian: accidentally capturing variables from the environment would be bad<br>
<fantasai> florian: so either don't capture at all, or capturing by opt-in seems more reasonable than just pulling everything in<br>
<fantasai> astearns: any other concerns?<br>
<fremy> (except if you have different functions names, then there is just no risk of conflict)<br>
<fantasai> astearns: ok done with this topic for now, let's get a draft and then poke hols in it<br>
<fantasai> s/hols/holes/<br>
<TabAtkins> Yes, given<br>
<TabAtkins> ```<br>
<TabAtkins> @mixin --foo(--arg1) using (--outer-var1) { color: var(--arg1); background: var(--outer-var1); }<br>
<TabAtkins> .foo { @apply --foo(var(--my-color)); }<br>
<TabAtkins> ```<br>
<TabAtkins> you'd effectively expand to:<br>
<TabAtkins> ```<br>
<TabAtkins> .foo { color: var(--my-color); background: var(--outer-var1); }<br>
<TabAtkins> ```<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9350#issuecomment-1939628591 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 21:38:23 UTC