Re: [csswg-drafts] [css-values] nested `calc()` is not defined by its grammar (#6506)

> The grammar of `<calc-value>` (Mathematical expressions - Syntax, CSS Values) does not seem to allow calc() to be used recursively and in other math functions.

The `<number> | <dimension> | <percentage>` part of the grammar covers that - those aren't the *token* productions, but the more generic value productions defined in V&U. In particular, `<dimension>` covers `<length>`, `<time>`, etc if you follow the link. *Any* function that resolves to a numeric value works there, such as `attr()` if it's specified to parse to a numeric type.

> The round() function accepts a component value that is not a calculation as its arguments: `<round()> = round( <rounding-strategy>?, <calc-sum>, <calc-sum> )`. Am I right to think that the above definition was written after adding round() to the specification?

Ah, yeah, that text predates `round()` appearing with its non-numeric argument. I'll fix.

> What is a "run" in "every consecutive run of values"?

I'm just using it as it standard English meaning, implying you take the maximal amount. In `1 * 2 * 3 * 4`, it's all four values.

> Does it really matter? I believe that the procedure to simplify a calculation tree will be able to process and return the same result for these 3 different structures anyway, but I'm just not sure why this "consecutive run" term is used.

In normal CSS it does not matter because it can't really be observed, but in Typed OM it's important because they'll produce different object graphs.

> Given the grammar of <calc-sum>, theoretically a sum can only receive <calc-product>. Is it correct that this means that a Product data structure is different from a component value matching the grammar of <calc-product>? If so, that's quite confusing to me. Is it about to avoid writing the grammar of <calc-sum> with <calc-value> | <calc-product> [ ['*' | '/'] <calc-product> ]?

No, it's just to properly handle the immediately preceding step. Starting with `1 * 2 * 3`, this is turned into the list `[1, *, 2, *, 3]`. Step 3 collects those into `[Product(1,2,3)]`. Step 4 then sees that there's only a single child, and lifts it up so that `values` is just the `Product(1,2,3)` node, rather than wrapping it in a useless `Sum(Product(1,2,3))`.

Contrast with `1 * 2 + 3`, where it starts as `[1, *, 2, +, 3]`, step 3 collects the first few into `[Product(1,2), +, 3]`, then Step 4 just dumps all of those items into a `Sum(Product(1,2), 3)` which *is* meaningful.

> Is it correct that root can only be a math function? If so, what is the reason for not using the math function term instead of an operator node that’s not one of the calc-operator nodes?

Yes, that's correct. The following steps handle the calc-operator nodes, so it seemed clearer and less prone to later editing mistakes to *explicitly* exclude them from this step, rather than use an inclusive term that *happens* to not include them.

> Also, it seems that none of the remaining steps of this procedure handle a math function containing non numeric values. Does a step 10. Return root is missing?

Are you referring to `round()` and its keyword argument? If so, then as I said above, that's just a missed edit that I'll fix.

If you're referring to anything else, can you provide an example? Non-numeric values in any other case should cause a parsing failure and thus never reach this algo.

> I see this note above the procedure to serialize a mathematical function:
>
> This section is still under discussion.
> 
> But access to the link target is restricted to W3C members.

Ugh, yeah it is; someone made a mistake and sent technical feedback to the private list in reply to a telcon agenda announcement.  Don't worry, it's not relevant anymore and I should just remove it.  (The behavior under discussion was resolved years ago and is widely implemented.)

> Is it possible to give me clues for the following terms that appear in the different steps of this procedure:
>
> * the root of the calculation tree fn represents
> * fn represents
> * the calculation tree’s root node is
>
> Do they mean different things?

No, they all mean the same thing. I'm just being a little loose with terminology there.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6506#issuecomment-896401642 using your GitHub account


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

Received on Wednesday, 11 August 2021 00:25:10 UTC