- From: Kevin Babbitt via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 Sep 2024 20:47:22 +0000
- To: public-css-archive@w3.org
> 1. Upgradeable commas, despite only being required for the handful of "arbitrary substitution functions" (toggle(), first-valid(), random(), mix(), etc), applies to all functions in the entire language. This is for consistency; it's a weird feature, and it would be even weirder, we believed, for it to only apply to a handful of function syntaxes. This means a decent bit of impl work to allow the "reparse upon encountering a semicolon" behavior for all existing functions, to no real author benefit.
> 1. Reparsing, kinda in general, isn't great for impls. We do it now for Nesting, to an extent, as it was unavoidable, but it would be nice to avoid that elsewhere when possible.
> 1. {} wrappers are "local" to the single problematic (comma-containing) argument, while comma-upgrading has to be applied to the entire function. Especially with longer functions, this might be easy to miss, causing some separate arguments to accidentally be parsed as a single comma-containing argument.
> 1. When you have a comma-separated list in the grammar, but the author only needs to supply a single item, _and_ that single item has a comma in it, comma-upgrading is kinda screwed. There is _no way_ to actually write this function, unless the grammar makes a special allowance for authors to put a bonus "comma" (aka a semicolon) after the last item (which is the current approach in `if()`.
Agree with all of these points and would support re-resolving in favor of "{} wrapper" (it was my preference in the previous straw poll).
--
GitHub Notification of comment by kbabbitt
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-2372357138 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 24 September 2024 20:47:23 UTC