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

Like I've said multiple times, we (the Working Group) already had this discussion, and made a decision about bare parentheses. If you want to religitate that decision *in general*, feel free to do so in a different issue. Until then, I'm sticking with the WG's previous decision on this matter.

(And I must emphasize *again* that "Prioritize" does not mean "Value regardless of all other factors". We *regularly* make syntax decisions that harm third-party tools because it's in the best interests of CSS. This *specific* decision was made several years ago, with *substantial* argument, because it would be *catastrophic* for Sass's parsing (and Sass was, and continues to be, one of the most (if not *the* most) used third-party tools), and there were plenty of other options for CSS that were just as good. A prioritization principle is a thumb on the scale, not an argument in and of itself.)

> 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.

And yes, this *is* additionally the argument I'm making. I don't want to waste time relitigating an already-settled decision when it's irrelevant in the first place because we already have a better option *and resolved on it*.

In particular - anything we use for grouping here, we *very likely* want to *never use anywhere else in CSS*. If we did use them somewhere else, then we *once again* have an ambiguous situation, where it's unclear whether the parens are part of the generic function syntax (and won't be read as part of the argument) or it's part of the argument itself; likely we'd end up needing to require people to double-wrap the values so the outer one can be part of the generic function syntax and the inner can be part of the value. That's relatively bad!

Using semicolons (or a few other characters that are similarly restricted from appearing in values due to existing parsing constraints) avoids that entirely, since they simply can't appear in a top-level value at all. Ambiguity is thus impossible.

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