[css-gaps-1] Grammar for expanded column-rule shorthand

[kbabbitt]

Gaps 1 extends the definitions of the column-rule-* properties to allow for lists of values. It would be desirable to expand support for multiple values to the column-rule shorthand as well. (and same for the row-* properties)

The existing column-rule property grammar is:

<'column-rule-width'> || <'column-rule-style'> || <'column-rule-color'>

The expanded column-rule property grammar I currently have drafted in Gaps 1 is:

<gap-rule-list>        = <gap-rule-or-repeat> [ / <gap-rule-or-repeat> ]*

<auto-gap-rule-list>   = [ [ <gap-rule-or-repeat> ] / ]*
                         <auto-repeat-gap-rule>
                         [ / [ <gap-rule-or-repeat> ] ]*

<gap-rule-or-repeat>   = [ <gap-rule> | <repeat-gap-rule> ]

<repeat-gap-rule>      = repeat( [ <integer [1,∞]> ] , [ <gap-rule> ]# )

<auto-repeat-gap-rule> = repeat( auto , [ <gap-rule> ]# )

<gap-rule>             = [ <line-width> || <line-style> || <color> ]

Note the introduction of the slashes to separate width-style-color tuples from each other. I introduced these because I wasn't sure if free-form mixing of subproperty values (for example, column-rule: 1px 5px solid black) would be sufficiently future-proof. I could have also used commas, but I'd prefer to reserve those for future extension of the grammar to support gap decoration areas.

In the initial proposal discussion and in the F2F meeting, I got some comments about the use of slashes:

@SebastianZ:

The mix of slashes and commas in the syntaxes needs to be discussed, especially in regard of a possible gap-rule shorthand (as mentioned in the explainer).

@tabatkins:

Yes, we need to be careful with this. In general we want to minimize the use of slashes; they tend to be confusing, especially when mixed with commas. (We're consistent with which separator wins wrt grouping, and this proposal follows that practice, but still.) Maybe we can do a cycling function or something to make it more obvious.

<dbaron> TabAtkins: I don't like use of slashes mixed with commas more than we usually like. We can do that later, such as with a wrapping function.

I wanted to get more input on this topic. I can see a few different options:

1. No separators needed; width/style/color values are distinguishable from each other and we're unlikely to run into future issues
2. Slashes, as currently drafted
3. Commas, because that would be consistent with other contexts such as backgrounds, borders, transitions, and animations, and we can figure out an alternative for gap decoration areas later
4. Some new functional notation for grouping, e.g. decoration() where the grammar inside the parenthesis takes at most one value or repeater for each of width/style/color

What do folks think?

[tabatkins]

@fantasai Brainstorming help requested here.

So, we've got gap-rule and its longhands (color, style, width). You can specify multiple gap rules, and they layout will cycle thru those.

Naively, our normal way of spelling that is a comma-separated list, aka gap-rule: 1px solid red, 1px solid blue;.

But a wrinkle: we have good use-cases to be able to set gap decorations differently in different areas of the grid. (See data tables for an example - different borders between cells in different areas.)

So, uh, how do? @kbabbitt's current suggestion is to use a /-separated list for the standard case of "the whole grid uses this one list of gap decorations", so that we have commas available to separate distinct areas and give them each their own list of gap decorations.

I'm not happiest about this; it reserves commas for the less common case, forcing authors to use slashes most of the time (they usually won't need commas at all).

But I'm unhappy about reversing this, either: having a comma-separated list of decorations, then use /s as a higher-level separator to separate each area+list of gap decorations.

I've tried to think of other variants, like a functional notation to group an area specifier + gap-deco list, but can't figure out how to get that to work either, especially with the longhands.

Best I've gotten so far is to be able to give an area specifier in each gap-deco entry, and then group the gap-deco entries with a given area specifier during processing. But that's repetitive. :(

Maybe we need to be able to define named gap-deco areas in a property, and then you can just supply the names with each gap-deco entry in the list? Like:

.grid {
  gap-rule-areas: --foo 1/2/3/4, --bar 5/6/7/8;
  gap-rule: 1px solid red, 2px dashed silver --foo, 2px dashed gray --foo;
}

This would define a single "general" gap deco (1px solid red), and then an alternating gap deco in the --foo area (silver vs gray).

This is theoretically the same as just "put an area specifier on each gap-deco entry", but the repetition is reduced and it's easier to see the grouping. It also means the grouping has a logical name which can be meaningful for the page.

[cdoublev]

I found this issue while looking for discussions to figure out how to serialize column-rule after declaring column-rule-width: repeat(auto, 1px 1px), because column-rule-width is defined with repeat(auto, <line-width>+) whereas column-rule is defined with repeat(auto, [<line-width> || <line-style> || <color>]#).

Anyway, I thought something like [<rule-area>] may be used as a separator:

.grid {
  gap-rule: 1px solid red, 2px solid red [2/2/4/4] 2px dashed silver, 2px dashed gray
}

This would define a single "general" gap rule alternating between 1px solid red and 2px solid red, and a gap rule targeting the area 2/2/4/4 alternating between 2px dashed silver and 2px dashed gray.

[kbabbitt]

.grid {
  gap-rule-areas: --foo 1/2/3/4, --bar 5/6/7/8;
  gap-rule: 1px solid red, 2px dashed silver --foo, 2px dashed gray --foo;
}

.grid {
  gap-rule: 1px solid red, 2px solid red [2/2/4/4] 2px dashed silver, 2px dashed gray
}

I like the idea behind both of these suggestions: Use the "which area it applies to" notation in some way to distinguish between different gap decoration areas in shorthands. I think these two suggestions are enough to convince me that option 3 from my original post is viable, and probably what we want:

3. Commas, because that would be consistent with other contexts such as backgrounds, borders, transitions, and animations, and we can figure out an alternative for gap decoration areas later

Agenda+ to resolve on that.