[css-values][css-images] Allow trailing comma in gradient functions (and probably others)

[upsuper]

Trailing comma can be visual pleasing with certain code styles, for example, this code piece from MDN:

body {
  background: linear-gradient(to right, 
     red 20%, orange 20% 40%, yellow 40% 60%, green 60% 80%, blue 80%);
}

can be written as

body {
  background: linear-gradient(
    to right,
    red 20%,
    orange 20% 40%,
    yellow 40% 60%,
    green 60% 80%,
    blue 80%,
  );
}

which may look better for some people.

This is currently invalid as trailing comma is not allowed.

It would probably be great if trailing comma is always accepted, like in many programming languages.

[AmeliaBR]

If we make this change, could we extend it to all comma-separated lists, not just gradient functions? E.g., background layers and such. Anything that uses the <item># syntax.

[upsuper]

I agree that it may be better to extend it to all comma-separated lists, thus I marked it css-values as well. It may make most of the sense for gradient functions, but it's indeed better with more consistency.

[Loirooriol]

If we make this change, could we extend it to all comma-separated lists

Maybe for all functions, but the ,; looks a bit odd for me in

background-image: url("image.png"),;

Though maybe some people would like this style in order to avoid touching the previous line when inserting some item at the end:

background-image:
  url("image1.png"),
  url("image2.png"),
;

Anyways, doing this for all # can have some strange implications for more general syntaxes.

For example, the syntax of background is <bg-layer># , <final-bg-layer>. So if we just allow a trailing comma after <bg-layer>#, then this would still be invalid:

background:
  url("image.png"),
  yellow,
;

but this would be valid:

background: url("image.png"),, yellow;

So instead of tying this to # lists, maybe the rule should be that ) and ; can be preceded by an optional comma or something like that.

[tabatkins]

Yes, the point of allowing ,; is for when you break across lines; it means you can reorder the lines or add/remove lines without having to touch other lines. This improves both editability and diffability.

Anyways, doing this for all # can have some strange implications for more general syntaxes.

We would indeed need to still manually apply trailing-comma in some properties,
but url("image.png"),,yellow would continue to be invalid due to the comma-elision rules if we did this.

Something like: # allows an optional trailing comma (but subject to elision rules, no doubled commas), and any function or property that contains a # or a literal , in its grammar allows an optional trailing comma at the end of its grammar.

[Loirooriol]

url("image.png"),,yellow would continue to be invalid due to the comma-elision rules

This doesn't seem clear to me. There is no omitted item between the commas, so the conditions in https://drafts.csswg.org/css-values/#comb-comma don't seem to apply.

Something like: # allows an optional trailing comma

But why? Wouldn't allowing it at the end of a function or property value be enough?

Allowing a comma after # seems problematic if you have a grammar like <ident># <ident>?. If the value is a, b, c, does it mean that a, b, c is the <ident># list and the final <ident>? is omitted? Or is a, b the <ident># list, , the optional comma, and c the final <ident>?, i.e. a synonym of a, b c?

[AmeliaBR]

if you have a grammar like <ident># <ident>?.

That's definitely something that needs to be defined explicitly. To use a real-world example: a background: url(image.png), blue is different from background: url(image.png) blue with respect to other background-list properties that override the declaration. For backwards compatibility, the comma always has to be meaningful in this case.

The optional comma should only be allowed either at the end of a value or at the end of a function parameter list.

[css-meeting-bot]

The CSS Working Group just discussed Allow trailing comma in gradient functions (and probably others).

The full IRC log of that discussion

<dael> Topic: Allow trailing comma in gradient functions (and probably others)
<dael> github: https://github.com//issues/4968
<dael> Rossen___: TabAtkins or AmeliaBR ?
<dael> AmeliaBR: I can talk about it if no one else wants to
<dael> Rossen___: Are we prepared? This was added by fan
<dael> AmeliaBR: Some in issue discussion
<dael> AmeliaBR: Feature request is to support a trailing comma in comma sep lists. Example was in a gradient function where adding or removing function stops and in course you have to fuss with making sure last item doesn't have a comma. That's annoying and can make diffs on version control more confusing
<dael> AmeliaBR: I commented that it's not just inside gradient functions. Same irritation when editing background or text-shadow lists
<dael> AmeliaBR: Remove one item and comments are all messed up
<castastrophe> +1
<Rossen___> q?
<dael> AmeliaBR: Valid comment from oriol is sometimes things get confusing in syntax in that we don't just have comma sep list. We have a comma sep list followed by something else. Like BG where final includes the color which is different
<dbaron> Is the proposed rule "allow just one trailing comma", or will there be other extra commas allowed?
<dael> AmeliaBR: Will be some fiddly issues about getting best way to define w/o breaking.
<dael> AmeliaBR: More general concern about trailing commas?
<dael> TabAtkins: Note my comment that oriol concern isn't something to worry about. We already have poss of successive commas in grammer. If you have a # multiplier followed by extra comma it's invalid 2 commas next to
<AmeliaBR> s/comments are all messed up/commas are all messed up/
<dael> TabAtkins: General is # multipler for comma list allows trailing comma. Any property with explicit comma or function with explicit allows final comma after syntax.
<bradk> Google Meet has 1.6 stars (out of 5) in the iOS App Store
<dael> TabAtkins: I think that ends up covering everything. I think we can define w/o special case.
<dael> AmeliaBR: You'll write up?
<chris> sounds great, do it Tab
<dael> TabAtkins: Definitely. Very much in favor b/c JS supports this everywhere. I support having a similar syntax in CSS
<dael> florian: Anyone looked at compat?
<dael> TabAtkins: It makes invalid things possibly valid which we're usually fine with. B/C it looks weird if you're not doing it I woudl be surprised at accidental usage
<dael> florian: If you say it's in JS and people want it it seems there's demand for syntax and disappointed it doesn't work. Could be left in stray stylesheets. I'm concerned b/c if you're trying to do this on a whole bunch of properties and functions if it's compatable in most but not all we end up inconsistent
<dael> TabAtkins: I suspect number of cases is 0. Even if non-0 but low number I'm okay with it. As long as it's small number of weird cases jsut like we have some functions allowing 0deg without unit I'm okay with a few exceptions. I don't think we'll need to
<dael> chris: Benefit outweighs risk of an oops somewhere.
<dael> emilio: Does that allow inside [missed]?
<dael> TabAtkins: I think it should. For same reason to allow easy re-order I suspect it should allow
<dael> emilio: Seems weird to special case comma but I guess it's most common
<dael> TabAtkins: Only sep we use in this case.
<dael> TabAtkins: Slash is a one off. Not used like commas in a way it would benefit
<dael> fantasai: Underfined lengths is a space. THat's the other one
<fantasai> s/Underfined/The only other separator we use for lists of undefined/
<dael> florian: About selectors it does make me worry about compat. I've done it multiple times. Probably some stray ones where I forgot to remove and I doubt I'm alone
<dael> chris: Trying to get rid of commas but allowed like rgb with a trailing comma acceptable?
<dael> TabAtkins: Comma form of grammar, yes
<dael> TabAtkins: To florian point- reasonable. If it ends up being that we can't do selectors I'm okay with that.
<smfr> q+
<Rossen___> ack dbaron
<dael> dbaron: If we're going to do funt and selectors should we do media lists for @\media?
<dael> TabAtkins: commas are allowed?
<dael> florian: Yeah, old syntax
<dael> dbaron: @\supports doesn't have commas, but @\media does
<dael> TabAtkins: Then yes, that too
<dbaron> s/funt/functions/
<Rossen___> ack smfr
<florian> s/old syntax/old syntax for "or"/
<dael> smfr: Seems weird to allow for bounded lists. If you do rgba it's weird for comma after. I guess this doesn't prop into computed style, right?
<fantasai> +1 to smfr
<dael> TabAtkins: COmputed style - correct we omit from serialization.
<dael> TabAtkins: First point, I don't agree limit to unbounded. In JS it's allowed in function arg which are usually bounded. Worthwhile to take long items and have trailing comma. I think it's reasonable here.
<dael> TabAtkins: True most color functions are short so no reason to put it there, but if everything else allows you want to be consistent
<dael> smfr: Mental model is comma is you can add an extra thing and tha'ts not bounded list
<dael> TabAtkins: Should be comma is a potential item. Basically same as ;. It separates properties but we think of it as an ender
<astearns> This seems like a good candidate for a preprocessor feature. Is it widely used in any preprocessors? If not, is that a reason not to add it to the language proper?
<dael> fremy: You can also re-order them. If the last one doesn't have a comma you have to rmove it. Even for lists where you can't add you can re-order arguments
<dael> drousso: What about when you can omit last semicolon in rule?
<dbaron> We also allow "color: red;;; background: blue"
<dael> TabAtkins: Can you elaborate in terms of the problem?
<dael> drousso: If you had something like a list of box-shadows as last rule. Allow trailing comma w/o semicolon after?
<dael> TabAtkins: Yes. Totally fine and not a syntax problem
<dael> drousso: okay
<dael> AmeliaBR: Closing brace is the endpoint. Comma has no special meaning
<dael> oriol: Concern with trailing comma if grammar has something after in the list. Could create ambig grammar. If you have a list of items sep by comma and at end you have a final optional item. Right now if value is a,b,c it's a 3 itme list. If you have a,b c you have c as final item
<AmeliaBR> example for Oriol's point: a `background: url(image.png), blue` is different from `background: url(image.png) blue`
<dael> oriol: Optional comma with a,b,c it's not clear if you ahve list of 3 items with last omitted or if there's 2 and the , after b is trailing.
<castastrophe> q: If the syntax is accepted, does that necessarily mean that's how it appears as the computed value? If you view the computed values of a property that has a function with a trailing comma, would the comma be stripped?
<dael> oriol: Not clear what we gain from allowing comma after any list. Better to allow at end of function bfore paran or value of property before ;
<fremy> @\oriol: yeah, but that's bad design in the first case ^_^
<astearns> castastrophe: I heard earlier that the comma would be stripped from the computed value
<dael> TabAtkins: Case you outlined I don't believe exists in CSS. Ignoring comma it's a bad designt o have suffix implicitly sep
<dael> AmeliaBR: Have example, bg list
<castastrophe> astearns +1 makes sense
<dael> TabAtkins: Comma separates final layer. oriol talking about a # multiplier, a space, and than more stuff.
<astearns> q+
<dael> AmeliaBR: b/c bg list has a literal comma that literal comma would superceed the optional trailing comma for parsing any any other properties with that pattern need similar syntax?
<dael> TabAtkins: not quite. b/c literal comma it's comma sep list with final item having different grammer. In oriol we have comma sep list with than more stuff but no separator. Have to recognize list has ended. Could be less clear with final comma. If grammar of stuff and comma sep items is potenitally ambig looks like one more item in the list
<dael> TabAtkins: Theoretically valid, but I don't think we do it
<dael> dbaron: Similar is font shorthand. Explicitly the comma sep list is last
<dael> TabAtkins: We dot hat a few times. It's not made ambig by this. Suffix thing we don't do
<dbaron> (The font shorthand is a bad design, we shouldn't do that again.)
<dael> oriol: I think that we are not gaining anything by letting this and we get potantial ambig. If we allow trailing comma after trailing we get he same without the ambig.
<dael> TabAtkins: I think you're right. Given they're at the end of the grammar just allow at end if fine
<AmeliaBR> s/dot hat/do that/
<dael> emilio: Prefer that. Lower level we define the less random interop bugs we'll find. Like someone handling parsing forgot hte trailing comma. If we define they're at the end of the block that's much preferable than sprinkling it around
<castastrophe> What about putting together a table of examples?
<AmeliaBR> s/ any any/ and any/
<dael> Rossen___: Point of order. THere's a bit or excitement to have this. THere's a number of cases that have to be discussed before we see the final shape of where trailing commas are allowed. With that we can resolve on adding the trailing commas and see what details are after you've spec text
<dael> Rossen___: Also we have a queue.
<chris> q?
<dael> astearns: To back up a bit. I've heard people talking about details on how it's possible but didn't hear much about motivation so I'm not sure people are enthusiastic. Seems this could be a pre-processor feature and I"m not sure it's been impl. Does anyone use this for CSS in preprocessor?
<dael> TabAtkins: Do not know. This is preprocessorable
<dael> astearns: miriam says it works in sass
<jensimmons> could miriam talk about this a bit?
<dael> astearns: Should look at how it impl in sass and see if it's popular. If it's not popular don't know why we should add
<dael> TabAtkins: I was going to suggest, it was usuful to get general support. I'm happy to explore further in issue and get resolution later
<dael> miriam: I know it's popular in many sass places. I don't know all the use cases. Would have to look closer in where we allow it. THat can also happen later.
<dael> Rossen___: Great, thank you
<castastrophe> Now I'm wondering if postcss supports it
<dael> Rossen___: We'll get a resolution with a more concrete proposal. Ideally miriam you can help with sass popularity

[tabatkins]

@AmeliaBR Ah, I didn't see your last comment before the call, and thus misunderstood your comment during the call. You're right, background is indeed ambiguous if we allow a trailing comma after the # term.

Since Oriol and Emilio both expressed preference for just allowing it at end of a function/property, and I don't think it negatively affects any existing property or function, I'm happy to switch to that.

So, that still leaves us with two possibilities, afaict.

1. Property or function grammars that contain either a top-level , combinator or # multiplier allow an optional final comma at the end of their value.
2. All properties and functions allow a trailing final comma that is stripped from their value by the Syntax parser.

If I understood them correctly, Emilio preferred handling this at the lowest level possible, to minimize the chance of someone forgetting to implement it, so they'd prefer (2). I think I'm okay with that. I first thought it was kinda weird to allow something like content: attr(foo,);, but then realized that if attr() had an optional comma-separated argument (which it does now in Values 4), that would be valid and fine; it's not great to have the validity of this change over time, so it's better to allow it all the time up-front.

This does allow oddities like color: blue,;, but heck, maybe someday we will make color comma-separated. And disallowing things that look weird but nobody will actually do isn't very important; we're not protecting anyone from anything. The gain in overall conceptual simplicity, since it would be addressed at the parser level, seems like a great win too.

So, when we pick this up (at the f2f I guess?) I propose that we accept (2), and I make edits to Syntax to make all functions and properties accept a final trailing comma, which is removed during parsing.

Specifically, I'd add a penultimate step to https://drafts.csswg.org/css-syntax/#consume-a-declaration dropping a single comma token, and add a similar bit dropping trailing ws and commas from the function value in https://drafts.csswg.org/css-syntax/#consume-function.

[mirisuzanne]

Sass doesn't have an easy way to track popularity of a feature, but it looks like we've supported trailing commas in many places since 3013, and basically everywhere since 2016. I'll dig deeper and see if I can find any exceptions, but I haven't found any yet. I can also try to survey use, if that's helpful.

Trailing commas on a single item are used internally to signify that the item should be treated as a list type, and we remove remove trailing commas when compiling to CSS. We do the same with trailing commas on a property:

$sass: item,; // -> a comma-separated list of one
.test { content:  $sass,; } // -> content: item;

I've most often seen it used in Sass list & map variables, though I often use it for gradients as well. My sense is that use in multi-line sass lists and maps is the norm rather than the exception. There was clamor in 2016 to allow it even more places than we did originally. But I also think people "trust" it more where the code is clearly a Sass-defined syntax (lists & maps), and are less likely to know we also support it in general CSS syntax (backgrounds, css functions, etc).

For a quick sample, this Sass:

body {
  background:
    linear-gradient(
      to right,
      red 20%,
      orange 20% 40%,
      yellow 40% 60%,
      green 60% 80%,
      blue 80%,
    ),
    linear-gradient(to top, black, transparent),
  ;
  width: clamp(0, 100%, 30em,),;
}

compiles to valid CSS without any trailing commas:

body {
  background: linear-gradient(to right, red 20%, orange 20% 40%, yellow 40% 60%, green 60% 80%, blue 80%), linear-gradient(to top, black, transparent);
  width: clamp(0, 100%, 30em);
}

[mirisuzanne]

We also support it where the number of accepted arguments is clear:

// example function accepts a single argument
@function example(
  $arg
) {
  @return $arg;
}

.test {
  error: example(a, b); // two arguments -> error
  valid: example(a,); // one with trailing comma -> `a`
}

[yisibl]

Not support trailing comma has been bothering me for years.
This makes version-control diffs cleaner and editing code might be less troublesome.

background-image: image-set(
  "cat.png" 1x,
  "cat-2x.png" 2x,
  "cat-print.png" 600dpi),
;

[css-meeting-bot]

The CSS Working Group just discussed #4968 Allow trailing comma in gradient functions (and probably others).

The full IRC log of that discussion

<dael> Topic: #4968 Allow trailing comma in gradient functions (and probably others)
<dael> github: https://github.com//issues/4968
<dael> TabAtkins: I think we're good. Previous hour was great and now we have a solid proposal.
<dael> TabAtkins: I won't go over the whole thing, just look at issue
<dael> TabAtkins: One concern from emilio during conversation is, WG in general suported trailing commas. Question was how. emilio concern was wanted it at low level, pref at parser so we didn't have to rely on impl remembering to put it in every place
<dael> TabAtkins: At first thought it was weird and my first idea of a funct without a comma was attr and then I remembered it allows comma sep now. My idea of comma-less functions that get upgraded has happened
<dael> TabAtkins: Same fo rpropreties, we've upgraded to be list valued. Some like color prob won't change, but we've done this in the past. My original objection is invalid, I support em
<Rossen_> q
<Rossen_> ack fantasai
<dael> TabAtkins: I prop we adjust consume a declaration, a function, and a comma sep so in addition to dropping whitespace they can drop a single comma token from the end.
<leaverou> +1, this will also make it easier to generate CSS
<dael> TabAtkins: if you have a parse close to syntax this allows it anywhere without much effort
<dael> TabAtkins: Syntax points: consume a declaration, consume a function, and new consume a comma sep list. All have an ammendment to consume a single comma token
<dael> florian: Do you want to include conditional lists and selector lists?
<dael> TabAtkins: Yes. the comma sep list thing was for those cases. I'd then redefine those to use that parsing algo.
<dael> florian: I suspect compat issues for selectors but let's see
<dael> florian: Properties that have comma sep list space and than a value do we have those?
<dael> TabAtkins: Don't as far as I know but they wouldn't be covered by this change
<myles> q+
<dael> TabAtkins: Trailing comma is at the end of the entire property declaration. The algo isn't invoked for properties.
<plinss> q+
<dael> florian: Do we have prop with comma sep list / other comma sep list?
<dael> TabAtkins: I don't think...
<tantek> I'm looking forward to when we allow 2 trailing commas TBH. Maybe next year? Maybe every year we can add another optional trailing comma?
<dael> fantasai: / is a more binding operator. If there are properties that have inverted the order of operation that's really bad. Comma is usually lowest
<Rossen_> q
<Rossen_> ack myles
<dael> myles: Seems reasonable for us to have a sinlge value prop today that turns space sep tomorrow with 2 values where we wouldn't have a comma in the middle. If we allow comma in all today couldn't do that
<dael> myles: Larger comment is commas make sense on lists not single value
<dael> TabAtkins: If we change syntax from one value to two space sep a comma wouldn't interfere. We wouldn't do something like counter reset, that was a mistake
<dael> myles: We use spaces and commas intentionally. Blanket stating for all doesn't seem forwardlooking
<dael> TabAtkins: Looks forward compat. If it was a,; and than we accept a b a, is fine a b is fine
<faceless2_> So "display: block,;" is valid?
<dael> myles: Not about ambiguity, we diesgin properties and want a comma or not a comma
<fantasai> yes, that's Tab's proposal
<dael> TabAtkins: Okay. objection to that, across css comma has been consistantly sept between repetitions of a list.
<dael> fantasai: Not true
<dael> fantasai: A lot of our funct it's not a list of thing.
<dael> TabAtkins: That's why I said properties.
<Rossen_> q?
<dael> TabAtkins: B/c consistant meaning there and trailing comma fine at end of one element list and not going to give comma another meaning when in a trailing position i don't think it's a forward compat issue
<dael> plinss: In favor but one concern.
<Rossen_> ack plinss
<dael> plinss: If you say foo, and nothing. If we define the second thing gets default value and it's important there are 2 things that's broken
<dael> TabAtkins: We would not define a repetition can be completely empty. We don't do that today. A value and atrailing comma is single value
<dael> plinss: This forces us into never allowing that. Never allow blank after comma is set in stone.
<dael> TabAtkins: Agree
<dael> AmeliaBR: How effect parsing of custom properties. When do we drop the comma? could be meaningful at end
<dael> TabAtkins: dropped during parsing. I can see it being confusing but I'm of the opinion that if you're putting structural stuff like that in your variable I think you'd in a world of pain
<emilio> q+
<dael> AmeliaBR: Real use cases where want custom property to be a list of repetitions or a blank. In that case don't want comma where you use custom property b/c invalid if it's a blank.
<dael> florian: Can we make an exception?
<dael> TabAtkins: Doable. A bit weird but not out of question
<dael> florian: Since it's a list of tokens it's a natural exception
<dael> AmeliaBR: Have an exception where a blank is meaningful
<dael> TabAtkins: That's not parser lever
<Rossen_> ack emilio
<dael> emilio: Not sure initial answer was correct. Parsing at property consumes all tokens regardless of which.
<dael> TabAtkins: Depends on definition. Id on't care what declarations name is while I'm consuming so parse the same and than apply grammar. I know browsers do grammer as you go but it's must simpler mental. That's why I'm okay adding a check for it it's parsed.
<dael> Rossen_: Time check, this will take us to the end. We have a queue and then let's see if we can end
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to ask for comparison between the two proposals
<oriol> q+
<dael> fantasai: Wanted to ask if we weren't going to do this for everything the alternative is only where there is a list. If we drew that up what would it look like and should we compare?
<dael> TabAtkins: Complicated. SImpliest is # multiplier allows trailing comma. BUt anything that does commas explicitly which is a lot would not work.
<dael> TabAtkins: Have to go into every prop that uses commas and make sure their grammer expresses it.
<dael> myles: I think that makes sense. Property by property is right
<dael> drousso: I agree
<faceless2_> +1 to myles
<Rossen_> Zakim, close queue
<Zakim> ok, Rossen_, the speaker queue is closed
<astearns> terrible to do things property by property for authors
<dael> TabAtkins: Disagree b/c it's fine and reasonable to do commas at end of single in JS. Having to distinguish for a way to write it easily seems unnecessary burdon on authors
<myles> q+
<Rossen_> q?
<dael> florian: I don't like it for rollout, if this is centeral it is fixed once. If it's property by property a fix would end up going out in some places but not all
<dael> myles: Difference between css and js is parsing rule isn't different by property in js. I don't understand argument that js has it in function calls so we have it everywhere
<dael> TabAtkins: Not strict, but reasoning is similar
<dael> oriol: Ask about trailing comma. In case there's an ! and if it's before the !important or if at very end
<dael> TabAtkins: Before the !important. End of value space and ! flag is after that
<dael> TabAtkins: I'd like to prop a resolution ad see if objections.
<florian> +1
<dael> TabAtkins: Prop: I make the syntax spec changes to allow trailing commas in general module small changes around things like !imoprtant
<dael> Rossen_: Obj?
<tantek> ES also allows it in arrays e.g. test =[1,2,]
<dael> myles: I'm not going to object but seems wrong direction
<tantek> not just functions, as a correction to myles's assertion that it's only functions
<TabAtkins> ES allows it *everywhere* now, yeah. [1,2,], {foo,bar,}, and foo(a,b,)
<dael> fantasai: Alternative way forward is TabAtkins has his prop and myles if you think there's a better way you can draft a proposal and we compare
<tantek> Thanks TabAtkins
<dael> emilio: Would myles agree on functions only and decide declarations at another time?
<dael> myles: Yes. Commas at end of lists is valuable
<dael> Rossen_: TabAtkins ?
<dael> TabAtkins: I think myles wants opposite of emilio
<drousso> that's not true TabAtkins something like `let x = 2,;` is not valid
<drousso> it's only allowed in places where a sequence/list/"multitude" is expected
<dael> emilio: Can we defer deciding if we add trailing commas for all declarations and agree we do it for comma separated list and function arguments?
<TabAtkins> drousso: Hm, time for a new ES proposal
<drousso> strong disagreee
<dael> florian: I think iw ould object property by property
<dael> fantasai: I prop that TabAtkins drafts a more specific proposal and myles and emilio discuss drafting a different proposal
<dael> TabAtkins: myles are you okay with trailing commas on functions?
<dael> myles: No opinions
<dael> TabAtkins: Let's resolve on that
<dael> smfr: Lists first
<dael> fantasai: Let's come back with something written specifically
<dael> Rossen_: I think that's be best path forward. Let's nto resolve by exhaustion. TabAtkins write your proposal. emilio and myles if you want a short at your proposal go ahead and draft that.

[litherum]

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 explicitly requires a trailing comma, and then explicitly add an optional 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.

[fantasai]

Overall makes sense to me.

Wrt the special cases, e.g. for 'background': typically the last item is unambiguously part of the final construction: it is required, and is not part of the "list". The last case is special because it allows things that aren't allowed in the generic list, but it can still match the generic list grammar: a given declaration might not necessarily include the parts which are "final" in the last item. Such a last item is not restricted to be the final item and the author could add more to the list afterwards. So it would be good to allow a trailing comma in these cases.

One way to do this would be to define a new multiplier which explicitly requires a trailing comma

We don't need to do that. These cases already have to include an explicit trailing comma in their grammar, otherwise the current grammars wouldn't actually work. :)

and then explicitly add an optional trailing comma after the last special item

Either that, or, if you want to disallow the comma after a final item pattern, make the last item pattern itself optional. This would make a grammar somewhat ambiguous: you don't know if you're in a "final item" pattern unless you hit one of the otherwise-disallowed components. But it would correctly represent all possible productions. E.g.

background: [ [ <layer># , ]? [ <final-layer> ]? ]!

instead of

background: [ <layer># , ]? <final-layer>

Note that the comma has special rules that prevent duplicates at a single point in the grammar, so # , does not create problems even if # allows a trailing comma.

p.s. I really dislike the ! multiplier as a solution to this grammar stuff, there's just too many brackets. Wish we had went with a combinator that meant "either or both but in this order".

[tabatkins]

I'm definitely not liking the special cases here. Each one sounds at least somewhat reasonable on their own, but the end result is that people have to think about where trailing commas are allowed or not (it's not obvious syntactically; you have to consider the value semantically), and spec writers have to think about how to structure their grammars to allow it in places that aren't covered by the single blanket "# can have trailing comma" rule.

All together, it's a lot of work on everyone's part, which authors will make annoying mistakes with and spec authors and implementors will get wrong and inconsistent, all for the dubious benefit of "no trailing commas in places where it doesn't quite make sense".

Extraneous/meaningless trailing commas aren't a problem in JS. You can put them on single-arg functions, you can put them on "fixed arg-length" functions, you can put them in tons of places. Just like in CSS, the distinction between "fixed-length" and "variadic" functions is purely semantic, not syntactic. The comma is just a separator that's allowed to end any comma-separated collection, so you don't have to think about where it's "appropriate" to have them; they're allowed anywhere you might expect them to be, automatically and all the time. I don't see why it's a problem for CSS to act the same way.

I'm still strongly supportive of @emilio's original position here, that we should make this a general syntax feature of CSS, not a grammar-specific feature that's allowed in some places but not others.

---

As an aside:

Wish we had went with a combinator that meant "either or both but in this order".

Remember that we ended up going with ! over that combinator because such a combinator would only support space-separation, and a lot of our examples for wanting this semantic, such as color() or image(), were using comma-separation. We'd either have had to create two variants of it (at least; a /-separated version might also be warranted) or we'd have only solved a subset of the cases we cared about and would still have had to do the awkward/unreadable grammars for commas; both of these possibilities were bad, so we rejected it and went with !.