Re: [csswg-drafts] [css-values-5][various] Better handling of arguments with commas (#9539)

After talking more internally in Chrome, especially in regards to the [`if()` syntax discussion](https://github.com/w3c/csswg-drafts/issues/10064), we'd like to revisit this resolution.

Note that it was resolved *just barely* in favor of the current approach - it went to a straw poll, and the voting was *tied* between "upgradeable commas" and "{} wrapper". (We decided in favor of upgradeable commas based on an instant runoff; it got more first-place votes.) I know that had @andruud attended that meeting, they'd have voted for "{} wrapper" and *against* upgradeable commas; possibly with another set of people we'd have gotten a result that leaned more strongly another way.

We've come to believe that there are a few good arguments against upgradeable commas, and in favor of {} wrapper instead. Some of them are impl-focused, others are author-focused:

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.
2. 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.
3. {} 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.
4. 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()`.

A fuller example for 4 could make things easier to understand. Say you were writing an `if()`, with a single conditional clause that resolves to `"foo.svg", "bar.svg"` when it's true. You'd want to write this as `if(cond(...): "foo.svg", "bar.svg")`, but *that's actually invalid* - the comma is an argument separator instead, so it's actually *two* conditional clauses, one saying `cond(...): "foo.svg"`, and then another saying `"bar.svg"` (which is an invalid conditional clause). The *only* way to resolve this is that the `if()` syntax proposal allows a trailing comma, so you can write it as `if(cond(...): "foo.svg", "bar.svg";)` (with a trailing semicolon), to cause it to be reparsed into a single conditional clause containing a comma. Not only the *UA's* parser has to restart - as a human reading it, I have to spot the trailing semicolon and realize that the earlier comma was actually part of the value rather than an argument separator.

On the other hand, if we used {} wrappers, you'd write it as `if(cond(): {"foo.svg", "bar.svg"})`.

* No reparsing needed
* It's clear from the start of the value that it's being explicitly grouped (*probably* because it contains a comma). 
* No need to realize that there's something weird about this case in particular that you need to work around, you'd just *always* have to wrap comma-containing values in {}.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9539#issuecomment-2371909637 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 17:36:03 UTC