[css-values-4] Simplification algorithm should possibly return single child for min/max

[johannesodland]

Step 5 for min/max of simplify a calculation tree currently states:

If root is a Min or Max node, attempt to partially simplify it:

For each node child of root’s children:

If child is a numeric value with enough information to compare magnitudes with another child of the same unit (see note in previous step), and there are other children of root that are numeric values with the same unit, combine all such children with the appropriate operator per root, and replace child with the result, removing all other child nodes involved.

Return root.

I might miss something, but this seems to simplify the children of the Min or Max node, but if you're left with only one child it seems to return the Min/Max node with a single child.

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:

If root has only a single child at this point, return the child. Otherwise, return root.

[cdoublev]

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).

[johannesodland]

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?

[cdoublev]

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.

[johannesodland]

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..

[cdoublev]

(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.

[tabatkins]

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.)

[css-meeting-bot]

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

The full IRC log of that discussion

<fantasai> scribe+
<fantasai> TabAtkins: Several years ago, we discussed simplifying calculation trees
<fantasai> TabAtkins: we agreed to aggressively simplify, e.g. min() if same units simplifies out
<fantasai> TabAtkins: as part of changes, I ended up removing the spec text about min() or max() with single argument
<fantasai> TabAtkins: I'm not sure why I dropped that spec text, I suspect it was an accident
<fantasai> TabAtkins: today all browsers do aggressively drop single-arg min()/max()
<fantasai> TabAtkins: e.g. min(5px) + 10px becomes 15px
<fantasai> TabAtkins: Chrome recently also aligned on this behavior
<dbaron> +1 to specifying what everyone does, seems like reasonable behavior.
<fantasai> TabAtkins: so I suggest we resolve on browser behavior, that single-arg min/max functions can be dropped from calc tree
<dbaron> (I think sakhapov recently wrote some reasonably major changes to calc() simplification in Chrome, to align with the spec.)
<fantasai> TabAtkins: even if the unit cannot yet be resolved
<fantasai> +1 from me
<fantasai> RESOLVED: Restore text simplifying out single-arg min/max functions

[tabatkins]

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.