- From: Matthew Dean via GitHub <sysbot+gh@w3.org>
- Date: Sat, 13 Feb 2021 03:58:22 +0000
- To: public-css-archive@w3.org
In addition, the CSS spec seems to define blocks (including curly blocks) very generically, and AFAIK doesn't _explicitly_ disallow the possibility that a CSS property won't be added that also can contain a curly value, like: ```css .box { new-prop: value1 value2 {value3}; } ``` This possibility, of course, would be devastating to CSS parsers with nested syntax if such a value could ever be assigned to a (non-custom) property. Not that that has to be a CSSWG concern, necessarily, but when I discovered that in CSS grammar I was like 😬 😬 😬 Also: > (We could theoretically still allow {} in the prelude of a body-less at-rule like @import, but that would prevent extension to a body-full rule later, and would just be a confusing sort of thing to allow.) This also would potentially be very bad for parsers outside of the browser, so I hope that doesn't come to pass either. So that is just to say, I think it would help if curly-brace blocks in CSS were defined less generically (than, say, square brackets or parentheses) in terms of where they will and won't appear. -- GitHub Notification of comment by matthew-dean Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5766#issuecomment-778558348 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 13 February 2021 03:58:24 UTC