[css-values] Allow sqrt(<length-percentage>)

[Crissov]

In b8935e7, @tabatkins has just added trigonometric and exponential functions to [css-values] as discussed in #2331. The commit includes a good explanation why hypot(A, B) is useful (beyond possible number range overflows) by supporting <length> instead of just <number>, like pow(A, B) does.

However, the argument only addresses pow(A, B). I wonder whether similar reasoning could be applied to sqrt(A) which is currently defined as a convenience alias for pow(A, 0.5). Please consider to change this to pow(A/a, 0.5)*a where a is unity with the same dimension and unit as A, e.g. 1px . This means, it would return the square root of the number of the value A using the original dimension (and unit) of A.

(This a could also be exposed as a separate function, e.g. unit(A) with unit(16px), unit(8px + 8px), unit(2 * 8px) all yielding 1px, and unit(1in + 2cm) as well because pixel is the canonical unit, while unit(2cm), unit(1cm + 1cm) and unit(2 * 1cm) should yield 1cm if possible in [css-typed-om]. I would have needed this recently to dynamically remove the length units from the translation components in a matrix().)

If the square root function supported <length>, there might be less reason for having a distinct hypot() function, but more reason to also introduce cbrt(A) for the cubic root and possibly squared(A) and cubed(A) for raising the number of the value A to the second (or third) power without affecting its unit and dimension.

While the square root function can be expressed by the power function with the terminating decimal fraction 0.5 as the exponent parameter, the cubic root requires an approximation to something like 0.333 or a calculation of 1/3. This may lead to unexpected effects due to binary rounding which could be avoided by a generic root(A, B) function which (almost) equals pow(A, 1/B), or perhaps by an inv(A) or rec(A) function that inverts the value to its reciprocal, i.e. calc(1/A), and could be evaluated at a later stage.

[Loirooriol]

The same reasoning for avoiding dimensions in pow applies to sqrt.

If 1em is 16px, then sqrt(1em) would give 1em, while sqrt(16px) would give 4px, or 0.25em, which are very different values for what should otherwise be identical input arguments! This sort of input dependency is troublesome for CSS, which generally allows values to be canonicalized freely; it also makes more complex expressions like sqrt(2em + 10px) difficult to interpret.

I don't really see how your other proposals are related to this issue, but root(<number>, <integer>) could be interesting because I guess pow(-8, 1/3) will be NaN like in JS, but root(-8, 3) could be -2.

[tabatkins]

@Loirooriol basically outlined why I don't want to do this. The difference in result between sqrt(1em) (returns 1em) and sqrt(16px) (returns 4px) is the big thing that I don't want to introduce; it's already cited in the reasoning for making pow() and sqrt() unitless-only.

The unit() function doesn't really work either, for several reasons:

• it fails completely on calculations like 5px + 10%, which don't have a mutual canonicalization at all
• it would presumably give a different answer for 1em vs 1em + 0px (resolving the latter to 1px)

I would have needed this recently to dynamically remove the length units from the translation components in a matrix().

Can you elaborate on this? The components of a matrix() that actually have a unit are all in the px unit (or 1/px), iirc.

[Crissov]

I donʼt feel strongly about this and understand the surprising effects it would have. It was a weak attempt to justify more convenience functions like cbrt(). (squared(A) is actually longer than pow(A, 2), but more readable in some cases.)

Why would pow(-8, 1/3) ever return NaN? JS is strange. CSS should not copy the strangeness.

As for transformation matrices equivalent to translation(var(--aLength)), I now realize that calc(var(--aLength) / 1px) would have sufficed to get a number that is really pixels.

[Loirooriol]

Why would pow(-8, 1/3) ever return NaN?

Probably because the principal root is complex, 2 e^((i pi) / 3). There is also the real root -2, but 1/3 is stored as a floating point number, which probably is not exactly the mathematical 1/3. If you add some error, the real solution may disappear.

But with root(-8, 3), now 3 can be required to be an integer, avoiding precision problems. Then we can know whether there is a real root or not.