[css-values-5][css-mixins-1] Add an if-test for local variables

[andruud]

Within a custom function, var() can refer to a local variable / parameter, e.g:

@function --add-one(--x) {
  result: calc(var(--x) + 1px);
}

The if() function has a style() test, which accepts a <style-query>. We should have a test which can reach local variables / parameters as well, such that you can do e.g.:

@function --select(--option) {
  result: if(
    test(--option: one): foo; 
    test(--option: two): bar;
    else: baz;
  );
}

One option could be to spec that if(style()) targets locals within a function context (i.e. it sees the same thing var() sees), but this might stretch the definition of "style". Otherwise, I guess we'll need to invent a new test.

[tabatkins]

I think just using style() is the right way to go. Local variables fully shadow custom properties in other contexts; it feels weird for style() to be able to pierce thru that and see all the way to the element. Also, the variable shadowing behavior is very intentionally meant to be able to let a caller override what a callee sees for custom props.

[css-meeting-bot]

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

The full IRC log of that discussion

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

[andruud]

With the model described in css-mixins-1 currently, we get the resolved behavior for free.