[css-mixins-1] Allow typed custom properties inside custom functions

[romainmenke]

See: #12315

I also found it a bit surprising that there is no way to have local typed custom properties. (except result)

@property --x {
  syntax: "<color>";
  inherits: true;
  initial-value: pink;
}

@function --foo() returns <color> {
  --x: rgb(255 0 0);
  
  result: if(
    style(--x: red): green;
    else: black;
  );
}

* {
  background-color: --foo(); /* black */
}

---

What was the original motivation to make everything untyped inside custom functions?

Because values are resolved in imaginary child elements nothing leaks out when a function is evaluated.
I can imagine that when the types are preserved it is possible to break custom functions by registering seemingly unrelated properties.

So maybe it should be possible to do local registrations?

[tabatkins]

What was the original motivation to make everything untyped inside custom functions?

To avoid locals inside of functions having to be aware of all properties defined outside, or having to be defensively named to avoid collisions.

It would suck to write a re-usable function that used a local --foo variable to hold some intermediate calculation, and have that function straight up fail to work, unpredictably, on certain pages because that page also uses --foo for something and registered it with an incompatible type.

Also, arguments establish local variables, and they have a type, which has no need to be consistent with outside registrations either.

[romainmenke]

Authors are surprised that typed custom properties do not work as they would expect: https://bsky.app/profile/css-only.dev/post/3lttqh2u7t22q

Would it be possible to allow @property definitions inside @function?
This still avoid conflicts without limiting capabilities.

@function --foo() returns <color> {
  @property --x {
    syntax: "<color>";
    inherits: true;
    initial-value: pink;
  }

  --x: rgb(255 0 0);
  
  result: if(
    style(--x: red): green;
    else: black;
  );
}

[tabatkins]

Hm, I see the argument for that. There's behavior you can get from inherited variables that you can't get from local variables, which isn't great. Most of the machinery of the registration isn't really necessary, tho - you honestly only need the syntax, right? Maybe we can just have a more limited syntax allowed in the function.

I keep looking for excuses to revive the using() prelude for some reason, lol, but having another "argument list" that just sets up some types for names you'll use in the body makes a lot of sense, I think. That is:

@function --foo() using(--x <color>) returns <color> {
  --x: rgb(255 0 0);
  
  result: if(
    style(--x: red): green;
    else: black;
  );
}

That would just affect the set of registrations visible while evaluating the body. I don't think we need to allow a "default value" in the using(), and honestly that would probably be a bit confusing - I think it would need to be an overriding initial value, instead, which means it would be different from the value in the arguments. Probably better just to disallow, and only let you specify the type; you can supply the "initial value" at the top of the body, like in the example above.

[romainmenke]

Seems great! Thank you.

Maybe just a different name than using, but even that I don't feel so strongly about :)

where(--x <color>)?

This is a function named --foo where --x is a color

[mirisuzanne]

@tabatkins

I think it would need to be an overriding initial value, instead, which means it would be different from the value in the arguments

I believe you, but don't follow the distinction you're making.

As a counter-point, authors will always want to provide a value to these variables, and we have a syntax for setting both the type and the value… So it sure seems nice if authors could use that syntax to do both at once.

[tabatkins]

In the arglist, --x <color>: red means that --x gets given the value "red" if and only if the function/mixin is invoked without passing that argument. It's a fallback, not the primary value.

In the wherelist, --x <color>: red would mean that --x starts with the value "red" at all times. It's not a fallback, it's just the way to set the value.

That feels different to me. But maybe I'm wrong? I could be convinced that they're actually consistent in meaning, like they're "arguments" that can't be passed (and so always get the default). Maybe that's the cleanest way to integrate them into the spec, anyway.

[mirisuzanne]

like they're "arguments" that can't be passed

Ah, yes, that's how I was thinking of them. Because I think my likely workaround with the current spec would be to define extra, private-by-some-convention arguments that I would not expect to override.

But it's also likely that some of these properties would want to reference values that are passed in as arguments. I'm not sure if parameter defaults can reference other arguments at this point? So that might be another distinction between the lists.

[tabatkins]

I'm not sure if parameter defaults can reference other arguments at this point?

They can, the spec handles them by treating all the arguments as custom properties and evaluating a rule, so they can all reference each other as long as you're not being cyclic, just like with multiple custom properties on a single element in a normal rule.