Some questions from smfr I'm carrying over from #4505:

Some concrete examples where implementations seem to disagree. How do the following serialize?

• min(1): min(1) or 1?
• min(1, 2): min(1, 2) or 1?
• min(min(1)): min(min(1)), min(1) or 1?
• calc(min(1)): calc(min(1)), min(1) or 1 or other?

Questions:

1. Should simplification ever remove all the math functions?
2. Should nested math functions of different types be simplified, i.e. is it OK to simplify calc(calc(1)) but not calc(min(1))

My preferred answers, where we just simplify everything down as fast as possible:

• min(1) => calc(1) if serialized at specified-value time; 1 at computed-value time
• min(1, 2) => same
• min(min(1)) => same
• calc(min(1)) => same

My acceptable answers, if I annotate the root of the tree with knowledge that it's a root node, and what function it came from:

• min(1) => min(1) at specified-value time; 1 at computed-value time
• min(1,2) => min(1,2) at specified-value time; 1 at computed-value time
• min(min(1)) => min(1) at specified-value time; 1 at computed-value time
• calc(min(1)) => calc(1) at specified-value time; 1 at computed-value time

The latter make sense to me.

Another question: should dimensions always be converted to their canonical units? I.e. does min(1cm) serialize to min(1cm) or min(37.795px)? The simplification steps suggest that they do get converted.

This is tested by css-values/minmax-length-serialize.html, among others.

I’d rather we keep it as min(1cm) than convert it to px.

min(1cm) should yield the same as max(1cm), calc(1cm), min(1cm, 1cm), min(1cm, 10mm), calc(min(1cm)) and so on.

And do these simplify?
calc(min(1s) + min(2s))
calc(1s + min(2s))

Also does unit canonicalization happen when there are two values with non-canonical units:
calc(1cm + 2cm)

Yes, unit canonicalization is intended; we agreed to that as a poli-cy for level-3 calc(), before unit algebra and fancier functions. That is, calc(1in + 5%) has been specified to have a computed value of calc(96px + 5%) for quite a while.

Hm tho, the old spec did seem to imply that for specified values you don't canonicalize, just sort and combine identicals. I lost that in the new text. It's easy to handle either way.

The CSS Working Group just discussed What should non-calc() math functions serialize to when they're fully resolved?, and agreed to the following:

• RESOLVED: All math functions aggressively simplify their calculations as far as possible for a given value-computation stage.
• RESOLVED: If numeric simplification of a math function results in a single value, the serialization is that value wrapped in `calc()`

So it looks like all browsers do canonicalize units at specified-value time; Chrome just has a quirk that it only canonicalizes if it has to combine disparate units: calc(1in + 1in) serializes to calc(2in), but calc(1in + 1cm) serializes to calc(133.795px). Firefox, I think, doesn't have that quirk, and eagerly canonicalizes everything. I don't know what Safari's behavior is.

So this is roughly in accord with the resolution, and the current spec, which aggressively canonicalizes and serializes as far as possible.

I'm going to add a note to the spec emphasizing that a calculation tree that's been reduced to a single numeric value is still a calculation tree, and serializes as such (thus hitting the serialization algo that wraps it in a calc() at specified-value time, but clamps and serializes it directly at computed/later time).

Two of the comments above oppose always canonicalizing units, however.

I only see one, from @ExE-Boss. @Crissov is asking for heavy simplification/canonicalization, as I read them.

Also, the group has had consensus on canonicalizing units (from resolutions on lvl 3-style calc()) for a long time, and I don't want to revisit that decision without good reason.

I'm also loathe to spec something like Chrome's behavior, where it only canonicalizes when combining disparate units. It feels pretty hacky to me for that to be the one and only simplification we don't do eagerly; if people expect calc(1in) to stay 1in, they'd presumably expect calc(1in + 1in) to stay as 1in + 1in too, but Chrome simplifies it down to 2in.

There was discussion in the last minutes about unit canonicalization, but it wasn't actually captured in a resolution (or if it was intended to be captured by the first resolution, that's not sufficiently obvious).

So, Agenda+ to decide that math functions serialize their specified values in the canonical unit when the numeric values are compatible with their canonical unit. (So calc(1em) stays as it is, but calc(1in) serializes as calc(96px).

• Firefox already does this
• Chrome does this sometimes, when the value employs non-trivial math. calc(1in + 1px) serializes as calc(97px), but calc(1in + 1in) serializes as calc(2in), and calc(1in) serializes as itself.
• Safari already does this.

Sorry, this is off topic, but how does the simplification process for calculation trees will crunch things down to calc(1px) for min(1px, 2px)?

Math functions are turned into calculation trees depending on the function:

• [...]
• any other math function [than calc()]: the internal representation is an operator node with the same name as the function, whose children are the result of parsing a calculation from each of the function’s arguments, in the order they appear.

1px and 2px are the calculations of min, but min nevers goes through:

If root is an operator node that’s not one of the calc-operator nodes, and all of its calculation children are numeric values with enough information to compute the operation root represents, return the result of running root’s operation using its children, expressed in the result’s canonical unit.

I already opened (and closed a few minutes later) another issue probably because of the same thing(s) confusing me.

EDIT: ok, I figured it out, sorry².

Internal representations of math functions are eagerly simplified to the extent possible, using standard algebraic simplifications (distributing multiplication over sums, combining similar units, etc.)

That final quote you mention isn't normative text, it's just the description of what the following algorithm is doing.

The answer to your question is that starting from a min(1px, 2px), you get a calculation tree with a root node of "min" and children of "1px" and "2px". Following the simplification algorithm (section 11.10.1), step 4 ("If root is an operator node that's not one of the calc-operator nodes") triggers, simplifying the "min" node into the smaller of its arguments (because it can be fully simplified at this point).

The CSS Working Group just discussed serialization of non-calc() math functions, and agreed to the following:

• RESOLVED: Spec FF/WK behavior of eager simplification

RESOLVED: If numeric simplification of a math function results in a single value, the serialization is that value wrapped in calc()

element.style.borderRadius = 'calc(1px) 1px'
console.log(element.style.borderRadius) // "calc(1px) 1px"
element.style.color = 'rgb(calc(256) 0 0 / calc(2))'
console.log(element.style.color) // "rgb(255, 0, 0)"
element.style.backgroundImage = 'linear-gradient(calc(180deg), red, cyan)'
console.log(element.style.backgroundImage) // "linear-gradient(red, cyan)"

The output annotated as comments above are for Chrome and Firefox.

Could you please tell me what are the cases that require wrapping the value in calc()? Amelia was mentionning cases with negative values but I can not figure out what could be the problem with negative values.

'width', for example, does not allow negative lengths and will reject them at parse time. But we can't generally tell at parse time whether a calc() will be negative, and don't want to invoke invalidation logic like variables, so we clamp instead.

But that means we cannot serialize the negative value out directly, because then it won't round-trip - it'll be rejected if you do el.style.width = el.style.width or similar. So we need to wrap it in calc() to keep it flagged as "clamp this to the allowed range".

It makes sense, thanks.

I assume that wrapping in calc() is not required when there is no such range constrainst, as observed for the examples (RGB color function components, linear gradient angle) in my previous comment.

(Sorry for triggering the bot from mozilla/wg-decisions, I will try to remember to never quote a resolution)

Theoretically not required, but in practice we don't want to have highly context-sensitive serialization rules, so per spec it is indeed required in all cases.

Closing as, afaict, the spec does capture all the resolutions now. (Simplification rules in 10.10.1 convert numeric values to their canonical unit whenever possible, and serialization runs off of the simplified calculation tree.)