Re: [csswg-drafts] [css-values][css-images] Allow trailing comma in gradient functions (and probably others) (#4968)

# Intro

This thread has already described how trailing commas are valuable in a variety of places. In this thread, there has been a [request]( to allow them in `linear-gradient()` and [in]( the background property. These both make sense, because they are (at least conceptually) lists.

We shouldn’t go wild here; it is possible to go too far. Writing systems all around the world use the comma to denote a separator between two or more things (clauses, list items, etc.). Using a comma in a context where it is not separating two or more things is actively misleading for users of these writing systems. Similarly, there has been an [argument]( in this thread about diffability when placing multiple values on different lines, but if there’s only one item, it’s very unlikely to need to be promoted to its own line.

# Proposal

We'd like to make a proposal according to this guiding principle: Trailing commas should be allowed on indeterminate lists, and nowhere else.

I understand the resistance to wanting to solve this property-by-property, so let’s consider the [multipliers]( defined in css-values-4. Here’s a proposal for a balance between the desire for trailing commas with the linguistic implications of commas:

- The asterisk, plus, and question mark shouldn’t accept trailing commas, because there was no comma inside the list. The commas don’t make sense in something like `grid-template-columns: 100px 1fr, [foo bar,] ;`.
- Similar reasoning for the bare curly braces. `contain-intrinsic-size: 10px 20px, ;` isn’t making anyone’s lives any easier.
- The hash mark should accept a trailing comma. `font-family: Helvetica, arial, sans-serif, ;` _does_ make sense.
- The hash followed by the curly braces (like `<length>#{1,4}`) can have a trailing comma, but not if the list is "full" - in this example, if 4 lengths are provided. Because the list isn't of indeterminate length, once the list is full, it can't accept additional values, so a trailing comma wouldn't help. For example, `border-style: dotted, dashed, ;` could have a trailing comma, but `border-style: dotted, dashed, solid, double;` couldn't.
- And that’s it. `font-weight: bold, ;` doesn’t make sense. `justify-content: safe left, ;` doesn’t make sense either.

# Implications

It’s pretty common in CSS to allow properties to have a “ / thing " suffix, like the `font` shorthand or the `rgb()` function. While I couldn’t find any examples that are of the form `bar # [ / baz ]?`, I expect that we may want to add something like this in the future. If we do this, I would expect the list part of the property would accept a trailing comma before, and not after, the “ / thing “ part. This supports diffing tools, as authors would be inserting values to the end of the list part, rather than the end of the entire property value.

CSS functions would abide by the above rules. For example, the `linear-gradient()` function ends with a `#` multiplier, so it gets a trailing comma, but `calc()` doesn’t end with a `#` multiplier, so it doesn’t. This makes intuitive sense: The `calc()` function doesn’t accept any comma anywhere, so there’s no reason to accept a trailing comma.

At-rule descriptors would abide by this too, for the same reason. Media queries would abide by this rule too, but as there are currently no media queries which include the hash mark in their grammar, there would be no change.

# Special Cases

There are a few places in CSS which are “lists where the last item is special.” One example as described [above]( is the `background` property. Another is the `color()` function. There are two ways we could go here:
1. Fixup in their grammar definition to allow a trailing comma after the special last item. One way to do this would be to define a new multiplier which doesn’t accept a trailing comma, and then explicitly add a trailing comma after the last special item.
2. Say that, because these special last items have to be the last item, they intentionally don't get a trailing comma. Nothing will ever come after them, so they don't need a comma afterwards. (Note that, according to the [definition of comma](, the double comma mentioned [here]( would be illegal: "a comma specified in the grammar must be omitted if ... multiple commas would be adjacent")

We don't have a strong opinion either way about whether 1 or 2 is chosen.

The CSSWG can support trailing commas where they make sense, without making CSS oppose authors' linguistic intuition.

GitHub Notification of comment by litherum
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 27 May 2020 16:34:13 UTC