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

And just to be clear about the actual spec text for this, we wouldn't allow {} wrappers just anywhere, so there's no need to upgrade the parsing of all functions, everywhere. Instead, it would be a change to the definition of the [comma-containing productions](https://drafts.csswg.org/css-values-5/#comma-containing-productions).

Currently (with the "upgradeable commas" feature), they're defined to *not* allow commas, *unless* the function is being reparsed in semicolon mode. (aka, if the function is currently in comma mode, the production ends at a comma or the `)` that ends the surrounding function)

With this change, instead they'd be defined in two branches. The production is either:
* a single {}-block, containing anything. (including commas, or more {} blocks, etc)
* a sequence of component values *other than* commas or {} blocks.

`var()` would get an explicit exemption here, as it needs (but, uh, currently doens't have *specced*) under the current approach. `var(--foo, "foo.svg", "bar.svg")` is valid today (resolving to `"foo.svg", "bar.svg"` is fallback is triggered) and almost certainly needs to be preserved. It doesn't actually run into the parsing issues that otherwise force this syntax feature, so it's just slightly unfortunate that it has to be inconsistent.

To aid in clarity, I'd probably swap them all to a new production, maybe `<any-argument>` (to parallel [`<any-value>`](https://drafts.csswg.org/css-syntax/#typedef-any-value)), which has these restrictions. `var()` would just stay with `<declaration-value>?`, as it has today.

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