Re: [csswg-drafts] [css-values-5][css-mixins-1] Add an if-test for local variables (#11455)

The CSS Working Group just discussed `[css-values-5][css-mixins-1] Add an if-test for local variables`, and agreed to the following:

* `RESOLVED: Style test of if() function sees function arguments shadowing custom properties`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> TabAtkins: andruud asked how should we allow you to test the value of arguments for a cuntion<br>
&lt;kbabbitt> ... using the if function which is already in values-5 there's a style test that will let you use custom properties<br>
&lt;kbabbitt> ... and resolve if they match particular value<br>
&lt;kbabbitt> ... but it wasn't super clear whether that should also work for function arguments<br>
&lt;kbabbitt> ... or if we should have a new form for if()<br>
&lt;kbabbitt> ... I argued that the design of how arguments work inside @function is intentionally to shadow custom properties<br>
&lt;kbabbitt> ... basically one list of -- names that var can access<br>
&lt;kbabbitt> ... and find nearerst thing that defines it<br>
&lt;kbabbitt> ... it would be weird if if() could pierec that shadowing<br>
&lt;kbabbitt> ... so we don't need to do anything special<br>
&lt;kbabbitt> ... andruud found that reasonable in private discussion<br>
&lt;kbabbitt> ... so unless someone has a great argument for testing custom prop on element that you can't otherwise access, i.e. if you use a var for  custom property name ....<br>
&lt;kizu> +1<br>
&lt;kbabbitt> ... then we'll resolve as said in thread where style test in function sees areguments as well as custom props<br>
&lt;lea> q?<br>
&lt;lea> q+<br>
&lt;astearns> ack lea<br>
&lt;kbabbitt> lea: in another issue we discussed expanding conditions of if to allow bare parens comparisons etc.<br>
&lt;kbabbitt> ... could this also fit there?<br>
&lt;kbabbitt> ... instead of adding more syntax, reference params with bare syntax<br>
&lt;kbabbitt> ... this also comes up with relative colors<br>
&lt;kbabbitt> ... want if() to evaluate on what color components are<br>
&lt;kbabbitt> TabAtkins: my preference is to not add any additional syntax, just reuse existing stuff from if()<br>
&lt;kbabbitt> ... which is style test<br>
&lt;kbabbitt> ... if we have shorter ways to write style test they;d appply here as well<br>
&lt;kbabbitt> lea: makes sense as long as we do add shorter ways<br>
&lt;miriam> +1<br>
&lt;kizu> q+<br>
&lt;astearns> ack kizu<br>
&lt;kbabbitt> kizu: there might be ways we could want to do this but not as part of style comparison<br>
&lt;kbabbitt> ... if we define local variable with something<br>
&lt;kbabbitt> ... or argument with soething<br>
&lt;kbabbitt> ... we could still want to get outer variable<br>
&lt;kbabbitt> ... different issue, we could resolve ???<br>
&lt;kbabbitt> ... different from this when you use condition or style, it's reasonable from author perspective to consider local variables, outer vars the same<br>
&lt;kbabbitt> Proposed: Style test of if() function sees function arguments shadowing custom properties<br>
&lt;kbabbitt> fantasai: which one is in shadow?<br>
&lt;kbabbitt> TabAtkins: if you have custom prop defined on element it's by default visible<br>
&lt;kbabbitt> ... but if function variable has same name you get that<br>
&lt;kbabbitt> fantasai: makes sense but not clear in resolution<br>
&lt;kbabbitt> ... a shadow can either be obscuring something or following it<br>
&lt;kbabbitt> TabAtkins: accept whatever verbage you want there<br>
&lt;kbabbitt> ... shadowing is standard term for it<br>
&lt;kbabbitt> ... I won't say it like that in spec, will use different verbage there<br>
&lt;kbabbitt> astearns: function arguments...<br>
&lt;dbaron> function arguments shadow custom properties?<br>
&lt;fantasai> PROPOSED: Style test of if() function see function arguments, falling back to custom properties?<br>
&lt;kbabbitt> RESOLVED: Style test of if() function sees function arguments shadowing custom properties<br>
&lt;kbabbitt> TabAtkins: meta: we want to prioritize @function rule for implementation<br>
&lt;kbabbitt> ... more attention to it would be great<br>
</details>


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


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

Received on Wednesday, 29 January 2025 21:29:32 UTC