That's silly. You want a +# multiplier, not a new type. We can add one, sure.

That's silly. You want a +# multiplier, not a new type. We can add one, sure.

Or just change the grammar to "( [ <number>+ ]# )". Syntactically the same, but semantically a little different, meaning "a comma separated list of space separated <number> values" instead of "a whitespace and/or comma separated list of <number> values".

Sebastian

<number-optional-number> is a list with minimum one, and maximum two items.
Maybe I'm missing something, but those proposed options would allow more than two wouldn't they?

Expressing comma-wsp is the problematic part, since there's no equivalent that allows either comma or whitespace.

The clearest equivalent currently seems to be
<number>{1,2} | <number>#{1,2}

I think this might be what @fantasai is suggesting, but maybe we could make a new token for a comma-wsp list? E.g. '&'
This would result in:
<number>&{1,2}

This would improve the <T>+# grammars we have in SVG, which while correct, aren't as clear semantically as they could be.

I don't know if we want to canonicalize the SVG "commas wherever you want" behavior in the grammar; making it slightly more annoying to type might help keep this from spreading to new things, so we can standardize on normal CSS behavior over time.

(For <foo>+#, we're gonna just add the +# combinator to V&U, so Bikeshedded specs will link to it automatically.)

If we were to standardize "comma or not whatever lol", I'd prefer hitting it directly. We already have +# for the "list of optional-comma things" (and theoretically could have +#{1,2}), we could make <foo> ,? <bar> directly indicate that the comma is optional.

That is already what it indicates, unless there's some new comma-specific grammar magic that overrides it.

SVG 2 has already gotten rid of <number-optional-number>, and Filter Effects should follow suit.
No need to add the confusion to CSS.

<number-optional-number> in SVG 1.1 was for values that could take one or two numbers; if two, they could be comma or space separated. E.g., for standard deviation of a blur, you can either give one value that applies in both directions, or you can give two different values, one for x-direction and one for y.

As you've all noted, there are lots of ways to express this syntax in standard CSS notation. I'm pretty sure <number>,?<number>? covers it given that CSS already makes whitespace optional so long as the tokenization is the same. Or <number>{1,2} | <number>#{1,2} as @nikosandronikos suggested.

For arbitrary-length lists of items separated by comma or whitespace, that's another matter. SVG has them all over the place, and the syntax we're currently using for SVG 2 is [<item>#]+, though we're quite happy to simplify that to <item>#+ if it gets added to CSS Values & Units.

If you then allow numerical qualifications on the #+ combinator, that would allow us to nicely encapsulate the syntax for other properties. For example, SVG viewBox would be <number>#+{4}: exactly 4 numbers, separated by any combination of whitespace or commas. E.g viewBox="0,0 50,50" is perfectly valid. (Aside: just added an SVG issue that the current syntax we have for viewBox is a mess.)

Besides the discussion about the type or multiplier, shouldn't SVG rather start discouraging mixed separator syntaxes? E.g. it doesn't make sense to allow viewBox="0 0 50,50", for example.
There was a lengthy discussion lately about the usage of commas as separators in color methods (see issue #266).

As I understand it, in CSS commas are normally used to separate list items, where an item is a coherent chunk of data. According to that the only valid syntax for viewBox would be viewBox="0 0 50 50", as the four values belong together.

Sebastian

@SebastianZ
That is a valid point, and one I'm sure @tabatkins will agree with. But it's not going to happen in SVG 2.

I do agree with the general move to a more logical & consistent approach to punctuation, even if I myself prefer the x,y syntax for coordinate pairs (with multiple coordinate pairs separated by spaces), as do many other people who come from a mathematical/scientific background.

When we CSS-ify viewBox, I'm sure there will be a push to switch to more restricted syntax, with the looser syntax only available in the attribute for backwards compatibility. This is pretty much what happened with transform.

CSSWG resolved today to formalize this "list with optional commas" pattern with the grammar form [ <foo>+ ]#. I'll add a note to V&U's definition of CSS grammar that this particular pattern, when used in legacy SVG properties, merely has the semantic meaning of "a comma-optional list", rather than what it appears to be, "a comma-separated list of space-separated lists".

It would be great if SVG could standardize on this grammar form as well.

OK, so you'd prefer if we standardize to have [<type>+]# instead of [<type>#]+ (which is what we're currently using in SVG 2)?

What about the cases where there are a fixed number of values, like the SVG 1.1 <number-optional-number> values? Any preferences? E.g., this is how @nikosandronikos fixed the viewBox syntax: <number> ,? <number> ,? <number> ,? <number> Not pretty, but clear & simple.

Aside: I just realized this is going to be a pain in the behind for spec-ing layered strokes, because when it comes to stroke-dasharray, we actually would want a comma-separated list of space-separated lists, but we're not going to be able to do that for backwards compatibility reasons.

Probably either way would work for SVG2; CSS tends to use [ + ]# because for many properties, commas are a higher-level separator. I agree the viewBox example above is pretty clear.