[css-values] # is easy to confuse with *

[SimonSapin]

https://drafts.csswg.org/css-values/#mult-comma introduces for grammars a # repetition which is like * but with comma separators. Terse grammars are nice, but in this case in this case this important difference seems easy to miss.

A couple times now I’ve reviewed a pull request from someone (not necessarily a new contributor) implementing CSS parsing from grammar in a spec like https://drafts.csswg.org/css-shapes-1/#funcdef-polygon . They do write a loop but don’t seem to realize that commas are required.

(Servo’s doesn’t use a parser generator for CSS. It’s manually-written recursive descent with one function or method for roughly each grammar term.)

In some specs (not css-shapes, which may be a bug) the # itself is a link to its definition in css-values, but even that is easy to miss.

I don’t know what to do about this, but it seems to be a recurring issue.

CC @tabatkins

[fantasai]

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 *?

[SimonSapin]

¯_(ツ)_/¯

[SimonSapin]

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.

[fantasai]

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

[SimonSapin]

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

[fantasai]

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

[gibson042]

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.

[SebastianZ]

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

[gibson042]

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

[gibson042]

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.

[fantasai]

Wow, we've been backported to IETF!