[csswg-drafts] [css-values-4] Do not simplify a calc Product node containing a non-canonical dimension unit (#7456)

cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values-4] Do not simplify a calc Product node containing a non-canonical dimension unit ==
Step 9.4 of [*simplifying a calculation tree*](https://drafts.csswg.org/css-values-4/#simplify-a-calculation-tree):

> If `root` contains only numeric values and/or Invert nodes containing numeric values, and multiplying the types of all the children [...] results in a type that matches any of the types that a math function can resolve to, return the result of multiplying all the values of the children [...], expressed in the result’s canonical unit.

I think *if `root` contains only numeric values* should be followed by *expressed in their canonical unit*, because there will not be enough information at parse time to convert a length expressed with viewport or font-relative units like in `calc(1em * 1)`.

I assume that parsing the calculation results into a non-simplified tree like `Product(1em, 1)` and that *multiplying the types of all the children* resolves to `Map { length → 1, percentHint: null }`, which *matches* `<length>`. Please forgive me if I missed/misunderstood something.

---

Please let me know if you think the following issues/questions deserves a new issue.

<details>

  <summary>What should be the simplified value of <code>clamp(1px, 1em, 1rem)</code>?</summary>

No value is returned from [*simplifying a calculation tree*](https://drafts.csswg.org/css-values-4/#simplify-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`*.

</details>

<details>

  <summary>Should parsing (and simplifying) apply bottom-up or top-down?</summary>

I cannot figure out whether parsing calculations and *turning* math functions into calculation trees should apply bottom-up granularly, or top-down as a flat list of component values, as well as to simplify a calculation tree. In [*parse a calculation*](https://drafts.csswg.org/css-values-4/#parse-a-calculation):

  > 5. At this point `values` is a tree of Sum, Product, Negate, and Invert nodes, with other types of values at the leaf nodes. Process the `leaf` nodes. For every leaf node `leaf` in `values`:
  >
  >     5.1 If `leaf` is a parenthesized simple block, replace `leaf` with the result of parsing a calculation from `leaf`’s contents.
  >     5.2 If `leaf` is a math function, replace `leaf` with the internal representation of that math function.
  >
  > 6. Return the result of *simplifying a calculation* tree from `values`.

  - at step 5.1, I cannot figure out whether the simple block should be associated to the result from parsing its calculation, or if its calculation should be parsed in this step
  - similarly, at step 5.2, I cannot figure out whether a math function should be associated to the result from *turning* it into a calculation tree (its internal representation, as a separate data structure), or if the math function should be actually *turned* into a calculation tree at this step

Similarly, I cannot figure out when *simplifying a calculation tree* should apply because the above step 6 simplifies calc-operator nodes but step 3 of [*simplifying a calculation tree*](https://drafts.csswg.org/css-values-4/#simplify-a-calculation-tree) also simplifies a math function from top to bottom:

  > 3. At this point, `root` is an operator node. Simplify all the calculation children of `root`.

I think that step 6 (simplification) can be removed from *parse a calculation*.

I have a working implementation but I'm unsure of some parts. Parsing applies from the bottom (calculation) to the top (level math function) but simplification only applies from the top (level math function) to the bottom (leaf node). This is the only model that gives me a `values` that is a tree of calc-operator nodes at the above step 5 when parsing `calc((1))`.

</details>

<details>

  <summary>Require the same resolved type for the calculations of <code>min()</code>, <code>max()</code>, <code>clamp()</code></summary>

The following requirement is defined for [`<round()>`, `<mod()>`, `<rem()>`](https://drafts.csswg.org/css-values-4/#round-func), [`<atan2()>`](https://drafts.csswg.org/css-values-4/#funcdef-atan2), [`<hypoth()>`](https://drafts.csswg.org/css-values-4/#funcdef-hypot):

  > 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()`](https://drafts.csswg.org/css-values-4/#comp-func).

The [related paragraphs in 10.9 Type Checking](https://drafts.csswg.org/css-values-4/#ref-for-math-function%E2%91%A0%E2%91%A6) 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.

Or if you want to group them according to the section they belong to:

  > - 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 `round()`, `mod()`, or `rem()` expression is the result of adding the types of its comma-separated calculations.
  > - The type of a `hypot()` expression is the result of adding the types of its comma-separated calculations.

</details>

<details>

  <summary>Improve hierarchy of sections 10.7</summary>

Section 10.7 is currently:

  - 10.7 Numeric Constants: `e`, `pi`
  - 10.7.1 Degenerate Numeric Constants: `infinity`, `-infinity`, `NaN`

I suggest:

  - 10.7 Numeric constants
  - 10.7.1 Basic mathematical constants: `e`, `pi`
  - 10.7.2 Degenerate Numeric Constants: `infinity`, `-infinity`, `NaN`

</details>

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7456 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 5 July 2022 13:47:07 UTC