[css-values-4] Should `pow()`/`sqrt()`/`sign()`/`abs()` only take calculations matching `<number>`?

[cdoublev]

pow() and sqrt() take calculations that must resolve to a <number>.

There is a note explaining why they only work with numbers. I understand the first argument but the second one confuses me:

[...] the result is dependent on what unit you’re expressing the argument in; if 1em is 16px, then pow(1em, 2) would give 1em, while pow(16px, 2) would give 256px, or 16em, which are very different values for what should otherwise be identical input arguments! [...]

First, expecting 1em as the result of pow(1em, 2) would be inconsistent with sign(1em) or abs(1em), which must wait for 1em to be resolved before evaluating their result:

Both of these functions operate on the fully simplified/resolved form of their arguments [...]

Or should sign() and abs() only work on numbers too?

Second, opacity: sqrt(100%) and color: lab(0 sqrt(100%) 0) are valid. But what is their resolved value? Or should pow() and sqrt() take calculations matching <number>?

edit: I realize the question also applies to trigonometric functions, exp(), log(), but I cannot think of a short title that would be appropriate.

[tabatkins]

First, expecting 1em as the result of pow(1em, 2) would be inconsistent with sign(1em) or abs(1em)

The note isn't about the expectations who have read and fully internalized the spec algorithms, it's about people just looking at pow(2em, 2) and guessing what it does. Most people would guess the result as 4em, and that's a reasonable thing to do. See, for example, this very old StackOverflow question (predating Sass's pow() support), where someone is discussing writing their own pow() function, and explicitly wanting to strip the unit off the first argument and put it back after the exponentiation.

Or should sign() and abs() only work on numbers too?

No, both of those act the same whether you use the argument as written or properly resolve it first. (Similarly, hypot() works the same either way, so it is allowed to take values with units, even tho internally it's squaring and square-rooting, both of which CSS won't let you do with unitted values.)

Second, opacity: sqrt(100%) and color: lab(0 sqrt(100%) 0) are valid.

They're not valid. Per "type of a calculation", the type of their argument is {"percent" -> 1}, which doesn't resolve to a number.

[cdoublev]

No, both of those act the same whether you use the argument as written or properly resolve it first.

Agreed for abs(), but the result of sign(1%) can be -1, the result of sign(1em) can be 0, and so on. However, returning the sign of the unresolved value would be useless. So, ok.

They're not valid.

I misinterpreted "a calculation which must resolve to a <number>" (or <angle>) in the definition of all these functions.

As hinted by your comment, this applies to the calculation type, not its value. That is, the calculation type must match <number>.

I do not want to be picky if the current wording is unambiguous. The thing is that there are many examples across the specs that define how a percentage resolves to a number or dimension.

But I also realized that allowing <percentage> resolving to <number> would implicitly require allowing <percentage> and <number> to be combined, otherwise pow(1%, 1) would be invalid anyway.

---

I would be grateful if you could give me an example of a definitely-invalid calculation that would appear possibly-valid when allowing <percentage> to resolve to <number>.

[cdoublev]

Oh, and if <percentage> resolving to <number> is not accepted in pow()/sqrt()/sign()/abs(), does that mean <percentage> resolving to <angle> is not accepted in sin()/cos()/tan()?

For example, background-image: conic-gradient(green calc(1deg * sin(50%)), black).

[tabatkins]

Why would that not be allowed? Again referring to "type of a calculation", that sin() argument has the type {"angle" -> 1} with a percent hint of "angle". That's valid for the sin() function, as it matches <angle>. sin() then resolves to the empty type {} with a percent hint of "angle", we multiply that by an angle, and end up with calc() having the type {"angle" -> 1} with a percent hint of "angle" again.

[cdoublev]

There is no reason for it to be invalid, indeed. It is currently invalid in Chrome and FF while calc(1deg * sin(1deg)) is valid, but probably for another reason (calc(1deg + 1%) is also an invalid <angle-percentage>).

[tabatkins]

Yeah, if they're not currently accepting mixed angles/percentages there, then it makes sense that mixing them in more complicated ways doesn't work either. Just a browser bug, then.