- 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
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> <dael> Topic: minimum nested pairs of parentheses in calc to 32<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3462#issuecomment-478408798<br> <dael> TabAtkins: Get a resolution that we should have limit on req. number nested parans that impl must support<br> <dael> TabAtkins: calc imposes min on terms but there's no spot where we allow you to fail with nested<br> <dael> TabAtkins: Prop: Put in a mandatory min for paren depth. Past that you're allowed to fail. Number is set to 32<br> <dael> fantasai: And this is a min, not a max.<br> <dael> florian: It's setting a min and saying when you fail how you do so?<br> <tantek> regrets+<br> <dael> TabAtkins: Yes, we have that term in other parts of calc so reuse<br> <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> <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> <dael> florian: If chrome inserts unnec parens it's probably wrong.<br> <dael> TabAtkins: Yep<br> <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> <dael> florian: Are we saying 32 included or excluded?<br> <dael> TabAtkins: I do not care. I'll put one down.<br> <dael> fremy: Similar question because it's a difference of one. Need to be clear if it's inside the code.<br> <dael> florian: As long as clear doesn't matter<br> <dael> fremy: Agree<br> <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> <dael> florian: But it's a min not a max.<br> <dael> astearns: We have a limit on terms which is 20, why choose different number?<br> <bkardell_> can someone explain why that is not a good assumption?<br> <bkardell_> (that you should be able to round-trip parse/serialize)<br> <fantasai> bkardell_, because browsers have bugs :)<br> <bkardell_> are these bugs not fixable?<br> <fantasai> bkardell_, in an ideal state, it should otherwise be a good assumption<br> <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> <fantasai> bkardell_, yes<br> <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> <bkardell_> fantasai: yes they are fixable, or yes they are not fixable? :)<br> <fantasai> bkardell_, fixable of course :)<br> <dael> TabAtkins: No. It doesn't count functions or parens so I need to update. When it's updated paren groups should count<br> <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> <dael> bkardell_: SO we want to spec so when done it's safe assumption?<br> <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> <dael> bkardell_: AS we spec it there should be a test that says that is a safe assumption<br> <dael> astearns: Should be a bug for a 32 paren that's parsed, you serialize, reparse, and then it works.<br> <dael> astearns: I believe prop is?<br> <dael> TabAtkins: Make the term limit consistent with nested parens limit<br> <dael> astearns: 2 resolutions. Set a min parens that is set at 32. Then raise min to 32<br> <AmeliaBR> s/raise min/raise min terms/<br> <dael> astearns: Obj to set minimum number of parenthesis to 32<br> <dael> RESOLVED: Set minimum number of parenthesis to 32<br> <dael> astearns: Obj to raise the number of expressions that must be handled to 32<br> <dael> RESOLVED: Raise the number of expressions that must be handled to 32<br> <dael> astearns: Lots of tests for all of this<br> <dael> florian: Writing a test is what prompted it<br> <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