- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Sep 2024 20:10:49 +0000
- To: public-css-archive@w3.org
hmmm yeah, I might agree that in this case going straight for a semicolon is the answer, given the rest of the structure so closely resembles the `prop: val;` syntax we're used to. The comma-upgrading is great when it's just a list of values, so it can look like a normal CSS function with simple values, but in this case the syntax is already funky. And that avoids the "one clause with a comma-containing value, with IACVT if it doesn't match" problem I'd cited earlier, which is nice and elegant. I also agree that allowing the final clause to end with the semicolon, and having that not mean anything semantic (just like in rules) is good. However, the "no else, just implicit catch-all" still fails due to the problems I cited previously - can't distinguish an empty catch-all from no catch-all, and can't distinguish a final test clause from a catch-all. You'd need to make the "bare catch-all" grammar specifically exclude some things and still have `else:` to let you write that stuff, like Anders suggested. Having to navigate those restrictions just doesn't feel worthwhile, versus just requiring the `else:` on the catch-all clause. So yeah, I think I support just going straight to using semicolons in this case. That means a grammar of: ``` if() = if( <<if-clause>> [ ';' <<if-clause>> ]* ';'? ) <if-clause> = <<if-cond>> ':' <<decl-value>> <if-cond> = <<boolean>> | else ``` -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10064#issuecomment-2332548055 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 September 2024 20:10:49 UTC