[css-values] minimum nested pairs of parentheses in calc to 32

[TalbotG]

calc-errors.html test at line 68

At line 68 of the test above, there is a calc() function with 128 nested parentheses. Firefox is able to support 128 pairs of nested parentheses. Blink supports 32 nested pairs of parentheses and then fails when trying 33 nested pairs of parentheses:

trac-webkit-calc-errors.html with 33 nested pairs of parentheses

128 nested pairs of parentheses seems outrageously extreme but there seems nothing in the CSS3 spec and CSS4 spec that indicate ceiling limit for nested parentheses.

Proposal: CSS4 spec explicitly state a limit (ceiling) of support to 32 nested pairs of parentheses in calc() function.

Then the test calc-errors.html should be adjusted accordingly before submitted to wpt.

[TalbotG]

Same issue in this

calc-errors.html test at line 59

[emilio]

Why? And why only on calc() and not on other (all?) CSS blocks?

[TalbotG]

There ought to be a reasonable ceiling limit to everything. 32 seems to me very reasonable.
Right now, Blink supports 32 but not 33 nested parentheses; Firefox supports 128.

and not on other (all?) CSS blocks?

Which other CSS blocks? I'm not sure I understand.

[emilio]

I mean why only on calc() and not on, e.g., nested @media rules and such?

[ewilligers]

Another example is CSS Selectors 4 :is(:not(...))

When the spec has no limits, implementations are forced to make their own choices between

• having well known and ignored stack overflow crashes, e.g. on fuzzer-generated input. The smallest example that crashes can change when moving to a different compiler version or when adding an unrelated feature.
• not using their implementation language's support for recursion, complicating their code and increasing the development cost of future features.
• choosing their own limits and making an intentional choice to fail any WPTs that go further.

[Martin-Pitt]

Ideally the limit should be a minimum so that authors can have guarantee and as technical limits matter less in the future the ceiling can be lifted and use cases may occur we did not realise.

A spec should never really have a maximum limit in my opinion.

Is there precedence for min/max limits? What about limits on amount of CSS selectors or how many CSS stylesheets you can import or link to? Is a limit here a dangerous precedent or would asking implementations to guarantee some minimum be more reasonable?

[TalbotG]

Right now, Firefox fails
calc-errors.html test
only because it supports much more than 32 nested parentheses; it supports 128 nested parentheses.

If we can not reach an agreement on a ceiling limit value on calc nested parentheses, the very least minimum to do will be to adjust such test.

[emilio]

That test is a WebKit-internal test, I don't see why Firefox would need to pass it.

[tabatkins]

CSS has never introduced actual maximums for anything. We have a few places where we've defined minimums that must be supported (with the implication that going over is implementation-defined and allowed to fail, in a particular spec-defined fashion).

@fantasai and I have tried to introduce such limits for all the numeric values, but haven't succeeded yet. :(

I'm happy to similarly define a maximum required nesting limit here. Presumably a separate nesting limit for rules vs values, since they're generally parsed in different phases?

When the spec has no limits, implementations are forced to make their own choices between [snip]

Crashing is never a reasonable behavior. ^_^

[TalbotG]

That test is a WebKit-internal test, I don't see why Firefox would need to pass it.

I will be submitting that test - most likely modified a bit - to WPT repository soon (say, within 6 weeks). So the test has to be modified somehow so that Firefox is not unfairly penalized (and does not fail) just because it supports 128 nested calc parentheses.

[Loirooriol]

I'm happy to similarly define a maximum required nesting limit here

@tabatkins Did you mean minimum? Otherwise, why add this inconsistency if minimums are used everywhere else?

[fantasai]

I would agree with setting a minimum, but not a maximum, in the spec.

As for the test, it could be written with as many parentheses as needed to pass in all known implementations, and also include a comment to the effect that if your UA is failing because you support more, then ask the test to be adjusted. It might also be worth separating out that test into its own file.

[TalbotG]

As for the test, it could be written with as many parentheses as needed to pass in all known implementations

I will eventually adjust that sub-test so that only 32 nested parentheses are used.
I am leaving this issue opened until this is done.

[tabatkins]

Sorry, yes, that's what I meant. Must support up to X degree of nesting; can support more but are not required to; must fail in a particular standardized way when the limit is exceeded.