[css-values-4] Calc-simplification mishandles unresolved percentages in product nodes

[AtkinsSJ]

For this CSS:

div {
    background-position-y: calc(2% * 2);
}

The first time that the calc simplification algorithm is run for this, (at the end of parse a calculation,) we end up in step 9.4:

If root contains only numeric values and/or Invert nodes containing numeric values, and multiplying the types of all the children (noting that the type of an Invert node is the inverse of its child’s type) results in a type that matches any of the types that a math function can resolve to, return the result of multiplying all the values of the children (noting that the value of an Invert node is the reciprocal of its child’s value), expressed in the result’s canonical unit.

The 2% numeric node has a type of «[ "length" → 1 ]», with a percent hint of "length" in determine the type of a calculation. Step 3 before this is unable to convert it to an actual number of pixels. However, the instructions in step 9.4 multiply its type and value with the 2 node anyway, producing a result with an apparent value of 4px.

It's possible that the note under step 4, "If a percentage is left at this point, it will usually block simplification of the node..." is intended to apply here and my example should not have reached step 9.4. If this is the case then it'd be helpful if that was clarified. However, the other steps explicitly handle percentages, so that doesn't seem to be the case.

Adding my own ad-hoc check in 9.4 to skip to step 9.5 for such percentages solves the issue, but does leave the result as calc(2% * 2) instead of 4%.

[cdoublev]

It's possible that the note under step 4, "If a percentage is left at this point, it will usually block simplification of the node..." is intended to apply here [...]

I think that was also my point in #7456, and that step 9.3 can distribute a number to another numeric value (not only a Sum) as the other remaining child.

[AtkinsSJ]

Thanks for taking a look at this!

Yes, step 9.3 applying to numeric values would be good. Perhaps as a separate step to avoid making the text too confusing.

I agree with your point in #7456 about them needing to be in canonical form too. I overlooked that in my implementation.