6. If root is a Negate node:
   1. If root’s child is a numeric value, return an equivalent numeric value, but with the value negated (0 - value).
   2. If root’s child is a Negate node, return the child’s child.
   3. Return root.
7. If root is an Invert node:
   1. If root’s child is a number (not a percentage or dimension) return the reciprocal of the child’s value.
   2. If root’s child is an Invert node, return the child’s child.
   3. Return root.

It should parse to Min(1em) but step 5 of simplifying a calculation tree does not unwrap 1em.

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

2. Return root

This is a niche case but I suggest to insert a step before step 2:

If root has only a single child, return this child.

No value is returned from simplifying a calculation tree when the math function is not min() or max() and all of its calculation children are [not] numeric values with enough information to compute the operation root represents (step 4).

I suggest to add:

10. Return root.

I am confused as to whether parsing calculations and simplifying calculation trees should granularly apply bottom-up, or top-down as a flat list of component values.

In parse a calculation:

• step 5.1 is unclear about whether the simple block should already represent a calculation tree or if its calculation should actually be parsed at this step
• step 5.2 is unclear about whether the math function should already represent a calculation tree or if the math function should actually be turned into a calculation tree at this step

Note: I have a working implementation parsing from bottom to top but simplifying from the top level math function.

2. If fn represents an infinite or NaN value: [...]

The current output for a specified value in Chrome is calc(1px + infinity * 1em).

I think the calculation should be parsed and simplified to Sum(1px, Product(Infinity em)). If the infinite value is not detected in step 2 of serialize a math function, I think it should be handled at step 2 of serialize a calculation tree in order to get the same output as in Chrome.

The following requirement is defined for <round()>, <mod()>, <rem()>, <atan2()>, <hypoth()>:

The argument calculations can resolve to any <number>, <dimension>, or <percentage>, but must have the same type, or else the function is invalid

But it is not defined for min(), max(), clamp().

The related paragraphs in 10.9 Type Checking can be merged:

Math functions themselves have types, according to their contained calculations:

• [...]
• The type of a min(), max(), or clamp() expression is the result of adding the types of its comma-separated calculations.
• [...]
• The type of a hypot(), round(), mod(), or rem() expression is the result of adding the types of its comma-separated calculations.