I don't really understand the confusion, given that # is not a multiplier in any other language that I've heard of. Why would someone just randomly decide it means *?

¯_(ツ)_/¯

Wild guess: it’s a combination of

• Prior knowledge tells you that a polygon is defined by multiple points so repetition is obvious
• The grammar is vaguely BNF-like
• No other grammar syntax that one has seen elsewhere has syntax that implies that some input characters are required, without using these characters (For what it’s worth, for example Rust macros use $( foo )* for repetition and $( foo ),* for comma-separated repetition.)
• The "This specification follows the CSS property definition conventions from [CSS21]" bit is in a boilerplate section that no-one reads, far from the grammar definitions. And it doesn’t even associate grammar syntax with css-values.

We should probably improve the boilerplate reference to V&U. Other than that, I don't really know what to do here. Comma is a literal in CSS, ,* would mean repeat lots of commas...

Yeah, unfortunately I don’t have a solution to propose. But it still seems to be a problem.

Perhaps I should write "So you want to add something CSS in Servo" documentation and advertise it to contributors (new and not) somehow. (Both on how to read specs in general and on Servo code in particular.)

I should maybe update https://www.w3.org/Style/CSS/read.en.html but it's a good place to start. :)

We should probably improve the boilerplate reference to V&U. Other than that, I don't really know what to do here. Comma is a literal in CSS, ,* would mean repeat lots of commas...

Don't the comma omission rules mean that top-level and argument-list value# and [ , value ]* are equivalent? It seems like # is just sugar, or at least resolvably close to it.

Don't the comma omission rules mean that top-level and argument-list value# and [ , value ]* are equivalent? It seems like # is just sugar, or at least resolvably close to it.

Yes. For what it's worth, I've just changed the syntaxes in CSS Backgrounds lately to use #. In my opinion value# looks much nicer than value [ , value ]* and I don't see why people should be confused about that.

Sebastian

Not value [ , value ]*, just [ , value ]*. That's why I referenced comma omission rules.

That said, I did find another example of indicating comma-separated sequences with # in RFC 7230 (though it might well have been inspired by e811c7f), and also prior art in an early draft of RFC 2234 from 1997 that didn't make it into the final version. So there's definitely a leg to stand on in keeping and using it.

Wow, we've been backported to IETF!

So... I'm closing this as no change, given that

• If you can't distinguish between different multipliers, that's a problem whether it's + and * or * and #, you should figure this thing out.
• We've deployed this across CSS for awhile now.
• We've got prior art from IETF.

Not value [ , value ]*, just [ , value ]*. That's why I referenced comma omission rules.

That's only equivalent to <value># if there's no terms preceding it in the grammar; if so, a preceding comma is actually required. Like, foo [, bar]* matches foo, bar, bar, while foo bar# matches foo bar, bar.

Also, it's significantly less readable / less obvious.