W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

Re: [csswg-drafts] [css-values] minimum nested pairs of parentheses in calc to 32 (#3462)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 Apr 2019 16:21:24 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-484160903-1555518083-sysbot+gh@w3.org>
The CSS Working Group just discussed `minimum nested pairs of parentheses in calc to 32`, and agreed to the following:

* `RESOLVED: Set minimum number of parenthesis to 32`
* `RESOLVED: Raise the number of expressions that must be handled to 32`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: minimum nested pairs of parentheses in calc to 32<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/3462#issuecomment-478408798<br>
&lt;dael> TabAtkins: Get a resolution that we should have limit on req. number nested parans that impl must support<br>
&lt;dael> TabAtkins: calc imposes min on terms but there's no spot where we allow you to fail with nested<br>
&lt;dael> TabAtkins: Prop: Put in a mandatory min for paren depth. Past that you're allowed to fail. Number is set to 32<br>
&lt;dael> fantasai: And this is a min, not a max.<br>
&lt;dael> florian: It's setting a min and saying when you fail how you do so?<br>
&lt;tantek> regrets+<br>
&lt;dael> TabAtkins: Yes, we have that term in other parts of calc so reuse<br>
&lt;dael> AmeliaBR: This is specfically about parsing nesting so this is literal parens not conseptual order of operations? Chrome when serializes adds a lot of parens so from authoring might be confusing. One paren with multi operations is it literal parens?<br>
&lt;dael> TabAtkins: It's a parsing problem so literal parens. Further order of operations can only impose one additional level so don't have to worry about that nesting indefinetly.<br>
&lt;dael> florian: If chrome inserts unnec parens it's probably wrong.<br>
&lt;dael> TabAtkins: Yep<br>
&lt;dael> AmeliaBR: True but I think 32 number comes out of chrome so not sure if anybody has tested how the 32 is counted in chrome and maybe has an effect?<br>
&lt;dael> florian: Are we saying 32 included or excluded?<br>
&lt;dael> TabAtkins: I do not care. I'll put one down.<br>
&lt;dael> fremy: Similar question because it's a difference of one. Need to be clear if it's inside the code.<br>
&lt;dael> florian: As long as clear doesn't matter<br>
&lt;dael> fremy: Agree<br>
&lt;dael> astearns: Serialization bug will be an extra problem if people using serialized values to set other prop. Importance of fixing prob. go up<br>
&lt;dael> florian: But it's a min not a max.<br>
&lt;dael> astearns: We have a limit on terms which is 20, why choose different number?<br>
&lt;bkardell_> can someone explain why that is not a good assumption?<br>
&lt;bkardell_> (that you should be able to round-trip parse/serialize)<br>
&lt;fantasai> bkardell_, because browsers have bugs :)<br>
&lt;bkardell_> are these bugs not fixable?<br>
&lt;fantasai> bkardell_, in an ideal state, it should otherwise be a good assumption<br>
&lt;dael> TabAtkins: 20 terms came because it seemed good. 32 is smallest limit across the browsers; Blink has 32. It would prob. be good to have similar numbers so I suggest raising term to 32 to make them symmertic<br>
&lt;fantasai> bkardell_, yes<br>
&lt;dael> AmeliaBR: I don't think it's conceptually possible to support 32 nesting and 20 terms. Doesn't bracket count as a term?<br>
&lt;bkardell_> fantasai: yes they are fixable, or yes they are not fixable? :)<br>
&lt;fantasai> bkardell_, fixable of course :)<br>
&lt;dael> TabAtkins: No. It doesn't count functions or parens so I need to update. When it's updated paren groups should count<br>
&lt;dael> astearns: bkardell_ asked on IRC about what's not a good assumption. We should not assume people writing serialization code and people writing paren code are talking to each other. Assuming if i's all chrome it'll work is bad.<br>
&lt;dael> bkardell_: SO we want to spec so when done it's safe assumption?<br>
&lt;dael> florian: We want chrome to fix bugs b/c having more parens in output then in input is not a thing that should happen. By shortest serialization it shouldn't do that<br>
&lt;dael> bkardell_: AS we spec it there should be a test that says that is a safe assumption<br>
&lt;dael> astearns: Should be a bug for a 32 paren that's parsed, you serialize, reparse, and then it works.<br>
&lt;dael> astearns: I believe prop is?<br>
&lt;dael> TabAtkins: Make the term limit consistent with nested parens limit<br>
&lt;dael> astearns: 2 resolutions. Set a min parens that is set at 32. Then raise min to 32<br>
&lt;AmeliaBR> s/raise min/raise min terms/<br>
&lt;dael> astearns: Obj to set minimum number of parenthesis to 32<br>
&lt;dael> RESOLVED: Set minimum number of parenthesis to 32<br>
&lt;dael> astearns: Obj to raise the number of expressions that must be handled to 32<br>
&lt;dael> RESOLVED: Raise the number of expressions that must be handled to 32<br>
&lt;dael> astearns: Lots of tests for all of this<br>
&lt;dael> florian: Writing a test is what prompted it<br>
&lt;dael> TabAtkins: For values stuff I'm enjoying writing tests so I'll make sure inputs go in with tests<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3462#issuecomment-484160903 using your GitHub account
Received on Wednesday, 17 April 2019 16:21:26 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:31:07 UTC