- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Mar 2024 16:11:21 +0000
- To: public-css-archive@w3.org
> Just mentioned in the call, but to highlight this, the argument against bare parentheses is in the first comment above:
>
> > (I'm rejecting using naked () for the same reason we ended up switching away from them for grid lines - it would mess up Sass syntax, and possibly others, hardcore, since in Sass it indicates math. I'm rejecting {} for "naive userland tools" reasons; again, many just split the text with regexes, and stray {} can screw them up. They're already potentially broken for custom props containing these chars, of course, but that's not an official Part Of CSS like this would be.)
That reasoning violates [TAG principle 2.12. Prioritize usability over compatibility with third-party tools](https://www.w3.org/TR/design-principles/#third-party-tools).
Literally every other language is using parens for grouping. If the argument is that semicolons as an optional upgrade are better or equivalent in terms of usability, that's one thing and I'm willing to accept it.
But we can't be forever unable to use bare parens and have to jump through hoops that hurt the usability of the language because a third-party tool is using parens for math! Third-party tools should *follow* CSS's design, not the other way around. And I believe last time this was discussed in the group, we largely had consensus on this among group members, with mainly Tab disagreeing. Perhaps we need to have a resolution about this, because I keep seeing this argument pop up.
--
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-1983869277 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 March 2024 16:11:22 UTC