I belive an earlier version of the spec did the same as the step for Sum nodes

You are right (see 56fb598). But I think I remember some discussions about preserving min(1em).

You are right (see 56fb598). But I think I remember some discussions about preserving min(1em).

Could it be related to #7456?

Should the Min node in min(1em) be preserved during parsing for internal representation?
It doesn't seem like it's preserved when simplifying for computed or used value though?

Could it be related to #7456?

No, this issue is about my misunderstandings (which still hold to this day) regarding the simplification of a Product node, and more generally, about the whole parsing/simplification procedures. I think I was thinking to #4399.

min(1em) should not be preserved at computed/used value time. I think 1em is resolved to an absolute px at step 1.2, then min() is resolved at step 4.

To be honest, I do not know what should be the serialization as a component of a specified value, for min(1em) as input. Based on current browser outputs, I would say calc(1em) but from reading the spec, the step you are suggesting seems to be missing, indeed. There do not appear to be any existing WPTs.

Did a quick test across browsers to check how they serialize the specified style:

Firefox: calc(1em)
Chrome: min(1em)
Safari: calc(1em)

I'm not sure how important this is though..

(Sorry to have temporarily closed the issue, due to a typing error.)

Chrome now outputs calc(1em).

I was trying to figure out which part of the simplification algo would allow FF to simplify abs(abs(-1%)) as calc(1%), and the step 4 seems to apply, which reminded me of this issue, for which it also applies, I think.

edit

Actually, FF should not simplify abs(abs(-1%)) as calc(1%). But I think abs(1%) would be fine, and my initial comment above remains valid for min/max() holding a single argument.

Should it not return the child in this case? I belive an earlier version of the spec did the same as the step for Sum nodes:

Note that removing a Sum node does not change the functional structure of the value; it just means that you don't have a silly Sum(5px) tree that just serializes to calc(5px) anyway. The same is not true of simplifying away other functions; that changes what the result looks like - Sum(5px + Min(10px)) serializes to calc(5px + min(10px)), rather than calc(15px) as if would if you removed the Min node.

But it does appear that browsers do exactly that simplification now, so I'm fine with making it.

(And I'm not really sure why I removed the Min/Max simplification in 56fb598#diff-fc1c32de78d227c8f0c8008469824444d1ba7f027e48a336125017d40b8f6f6fL4283; the minutes in #4399 don't suggest we stop doing that.)

The CSS Working Group just discussed [css-values-4] Simplification algorithm should possibly return single child for min/max, and agreed to the following:

• RESOLVED: Restore text simplifying out single-arg min/max functions

As far as I can tell, the reason I removed the explicit "min()/max() is dropped if it has only one child" is that I figured it was covered by the generic "replace a node with its result if you can", and just didn't realize that the restrictions I placed on that clause ("in the canonical unit") would be too restrictive.

Anyway, restored now; as part of the special min/max "partial simplification" it'll replace itself with its sole child regardless of whether the child is fully resolveable yet.