[css-values] Serialize all functions in summation

[ewilligers]

We previously only allowed for min and max in summation.
https://drafts.csswg.org/css-values-4/#math-function-serialize-a-summation

We can now also have clamp, sin, ..., hypot.

[ewilligers]

A summation may also contain products or quotients of functions. I suspect they should also have their order unchanged. calc(1 + calc(2px / 2em) + 3 + sqrt(16) + calc(5px / 5em)) should become calc(4 + calc(2px / 2em) + sqrt(16) + calc(5px / 5em))

[AmeliaBR]

calc(1 + calc(2px / 2em) + 3 + sqrt(16) + calc(5px / 5em)) should become
calc(4 + calc(2px / 2em) + sqrt(16) + calc(5px / 5em))

The nested calc() should be dropped in favour of simple parentheses per the rules on simplifying a calculation. But you're correct that this complicates the sort order considerably, since terms can have all sorts of combinations of units.

I believe the whole purpose of sorting terms at all is so that two algebraically equal expressions have the same simplification. To be consistent with that goal, we should probably define full sorting rules for complex dimensions (e.g., by number of dimensions and then alphabetically by numerator units and then by denominator units and then by numerical magnitude...) and for functions (e.g., alphabetically by function name). So, your equation would be more like:

calc(4 + (2px / 2em) + (5px / 5em) + sqrt(16))

However, since serialization currently supports algebraic simplification, we could expect it to combine terms with equivalent dimensions, and maybe compute out trig functions of simple numbers:

calc(8 + (2px / 1em) )

Either way, we need a spec! But I see no problem with merging your simple PR and then opening a separate issue for the full discussion.

[tabatkins]

Yeah, this is acceptable for now. I don't think we want to do additional sorting into the complex terms; the value seems very low for the effort required for all parties.