[css-values]: Proposal – Add type conversion functions to mathematical expressions

[SetTrend]

Current Situation

Code like the following does not work:

div
{
  --size: 2px;
  width: calc(1px * pow(var(--size), 2));
}

This is because the --size variable is declared as a length value, not a bare decimal value (see https://stackoverflow.com/questions/79894255/why-do-css-functions-like-pow-not-work-in-browsers).

Desired Situation

It is desirable to use "typed" values ​​for variables instead of simple decimal numbers so that they have semantics. Moreover, the unit information is important, as using a different unit can dramatically change the design.

CSS mathematical expressions, however, don't accept length or percentage values. They require bare decimal values.

Improvement Suggestion

To keep things concise and to avoid introducing breaking changes, I propose to add two new conversion functions to the CSS spec (one with an overload).

Function name	Description
v(arg)	Returns the decimal value from the specified argument unit value.
u(arg)	Replaces the decimal number value from the specified argument unit value with a 1 and returns the unit identity value.
u(arg1, arg2)	Replaces the decimal number value from the specified first argument unit value with the second argument decimal number and returns the corresponding unit value.

Synopsis

• The proposed conversion functions will be used quite often, so their name should be short (u() and v() in this case).

Details

v(arg)

• v(arg) takes a single argument.
• The single argument may be any decimal number value with optional unit.
• The v(arg) function strips the unit and returns the decimal number value only.
• If the argument is a decimal number without unit, the v() function returns the decimal number without change.

u(arg)

• u(arg) takes a single argument.
• The single argument may be any CSS value with a unit.
• The u(arg) function replaces the decimal number with the constant value 1 and returns the typed identity unit value.

u(arg1, arg2)

• u(arg1, arg2) takes two arguments.
• The first argument may be any CSS value with a unit.
• The second argument may be any CSS value; either a decimal number or a value with a unit.
• The u(arg1, arg2) function replaces the decimal number from the first argument with the decimal value from the second argument and returns the typed unit value with the decimal value from the second and the unit from the first argument.

Examples

• v(23px) returns 23
• v(5%) returns 5
• v(45deg) returns 45
• v(789) returns 789

• u(23px) returns 1px
• u(1rem) returns 1rem
• u(0%) returns 1%
• u(-45deg) returns 1deg

• u(23px, 5) returns 5px
• u(1rem, 25px) returns 25rem
• u(0%, 111deg) returns 111%
• u(-45deg, -123) returns -123deg

Result

Using the proposed two new conversion functions, the above described problem could be solved like this:

A

div
{
  --size: 2px;
  width: calc(u(var(--size)) * pow(v(var(--size)), 2));
}

B

div
{
  --size: 2px;
  width: u(pow(v(var(--size)), 2), var(--size));
}

[Loirooriol]

This doesn't work in general.

E.g. what should v(1px + 2em + 3pt) be? or imagine 1em = 16px, then v(1em) would be expected to be the same as v(16px), but the former is 1 and the later 16.

This has been discussed multiple times, e.g. see the explanation in https://www.w3.org/TR/css-values-4/#ref-for-funcdef-hypot%E2%91%A1 or #9668

Instead, you should just divide:

div {
  --size: 2px;
  width: calc(1px * pow(var(--size) / 1px, 2));
}

Then it's up to you to provide the unit that makes sense in that context.

[SetTrend]

In your comment, you overlooked that I declared the function arguments as "decimal value or decimal value with a unit." The proposed functions do not accept expressions—just like other CSS functions (except calc(), calc-size(), and the like) don’t take expressions.

In your example, the correct way to use u() or v() with an expression would be to use calc(): v(calc(1px + 2em + 3pt)).

[SetTrend]

Instead, you should just divide:

div {
--size: 2px;
width: calc(1px * pow(var(--size) / 1px, 2));
}

This would create too many dependencies on the unit. If you'd change --size: 2px to, e.g., --size: 2em, you would also need to update the width: rule.

[Loirooriol]

OK, so they wouldn't be math functions. It's still not clear what v(calc(1px + 2em + 3pt)) is supposed to be, though.

This would create too many dependencies on the unit

More like it's not dependent on --size's unit, and you want it to be, so you would need to update width in order to achieve that. And my point is that not being dependent on --size's unit is generally a good thing. You have not provided an explanation of why you want that dependency.

[SetTrend]

It's still not clear what v(calc(1px + 2em + 3pt)) is supposed to be, though.

v(calc(1px + 2em + 3pt))   ⇒   v(37px)   ⇒   37

This would create too many dependencies on the unit

More like it's not dependent on --size's unit, and you want it to be,

Exactly. If a calculation depends on a variable value unit, it still must resolve when the unit changes.

If this is not desired, just don't use u(). Using u() is a proposed option for those cases when this behavior is desired.

[Loirooriol]

v(calc(1px + 2em + 3pt)) ⇒ v(37px)

And why are you resolving calc(1px + 2em + 3pt) into px? With v(2em) you want 2 and not 32, right? What about v(calc(2em))? It looks inconsistent.

Using u() is a proposed option for those cases when this behavior is desired.

Sure, please explain why you desire this in more detail.

[SetTrend]

I was merely giving an example. The calc() function either returns a bare decimal value or a decimal value with a unit. And that's the input to the proposed v() function. The result of the calc() function is out of scope here. There is no inconsistency. v() deals with a bare decimal value or a decimal value with a unit, nothing else.

Sure, please explain why you desire this in more detail.

Let me give an example:

--size: 5em;
perspective: calc(var(--size) * 500);
transform-origin: calc(var(--size) * 1.5) calc(var(--size) * .5) calc(u(var(--size)) * sqrt(pow(v(var(--size)), 2) - pow(v(var(--size)) / 2, 2)) / 3);

[Loirooriol]

The calc() function either returns a bare decimal value or a decimal value with a unit

Not really, calc() can represent values that can't be expressed using literals.

I see 2 possibilities, and I'm not sure which one you are arguing for:

• v() only accepts literals (similar to <zero>), so calc() is invalid.
• v() accepts an arbitrary <number> | <dimension> | <percentage>, so it needs to deal with calc(), and this is not "out of scope here".

The former makes more sense to me.

Let me give an example

You example is not supporting your point. The 3rd component resolves to calc(1em * sqrt(3) * 5 / 6).

If, let's say 1em = 16px, and you were to use --size: 80px, then it would be calc(1px * sqrt(3) * 80 / 6), which is the same as above.

So you could just use calc(1px * sqrt(pow(var(--size) / 1px, 2) - pow(var(--size) / 2px, 2)) / 3) to get the same behavior, no need for v() and u().

[Crissov]

In the example(s) presented here so far, the unit is always remultiplied with the modified unit-less value: u(foo) * func(v(foo)). The same result can be achieved with a constant value (like 1px) already: bar * func(foo / bar). The only difference is that the author chooses the unit of that constant. progress(foo, 0, 1)

In the latest example, calc(u(var(--size)) * sqrt(pow(v(var(--size)), 2) - pow(v(var(--size)) / 2, 2)) / 3) can be simplified to calc(var(--size) / sqrt(12)) if my math is not mistaken, but I assume there is a systematic formula in there. If some calculations like that are frequently needed or at least helpful, it may actually make more sense to add specialized math functions to CSS (like hypot() for the hypotenuse of a right triangle, the diameter of a rectangle or, generally, the Euclidean norm) than it would to introduce unit conversion functions.

Authors might also find clever ways to use other existing functions like calc-mix() or, more interestingly, calc-interpolate(), e.g. with cubic-bezier(), in clever ways that avoid unit conversion.

[SetTrend]

@Loirooriol:

It seems to me you are barking at the wrong tree …

As described in the OP, calc() may return a scalar value (incl. optional unit identifier). If that's the case, v() and u() take the results. If calc() returns anything else, it's a type error. End of line. I don't get your point of confusion here.

@Crissov:

Again, this is just an example, an MRE (minimum-reproducible-example). — Let's not waste our time tracing a path in an MRE that is not in focus of the original proposal here.

[Crissov]

It may be an example but it is not yet a use case nor an argument. We are trying to help you make your point, actually.

[SetTrend]

From my perspective, the use case and everything else is comprehensively given in the OP. Everything else seems to me like not understanding what I wrote.