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

[kbabbitt]

Drafted the changes here: kbabbitt@a5a5e8e

[css-meeting-bot]

The CSS Working Group just discussed [css-gaps-1] Grammar for expanded column-rule shorthand, and agreed to the following:

• RESOLVED: accept the PR to solve this issue

The full IRC log of that discussion

<fantasai> kbabbitt: First issue is about gap rule shorthand
<fantasai> kbabbitt: In the future, I wanted to allow different parts of container ot have different gap decorations
<fantasai> kbabbitt: In the current version of the spec, we allow for varying gap decorations within a given region o the container
<fantasai> kbabbitt: For the purposes of the shorthand, specify widths styles colors ...
<fantasai> kbabbitt: For longhand properties to do varying decorations, can specify them all: columnrule-color: red blue ; alternate red/blue
<fantasai> kbabbitt: For shorthand it's more complicated because of additional values
<fantasai> kbabbitt: I previously used slashes to separate width/style/color groups
<fantasai> kbabbitt: wanted to reserve commas for future feature for regions
<fantasai> kbabbitt: Got feedback that slashes were not great for this particular separation
<fantasai> kbabbitt: subsequent discussion, several pointed out that when that feature comes along, we'll need to specify which region each set applies to
<fantasai> kbabbitt: identify the region of the container
<fantasai> kbabbitt: so we could use those indicators as the separators for this set of decorators applies to this region of the grid etc.
<fantasai> kbabbitt: that seems reasonable to me
<fantasai> kbabbitt: indicates that it's safe to use comma for separators for varying decorators within a section
<fantasai> kbabbitt: so that's what I would like to do
<emeyer> scribe+
<astearns> ack fantasai
<emeyer> fantasai: border-radius has a similar problem trying to assign things to different positions
<emeyer> …It also wanted to make sure it had the ability to use repitition
<emeyer> …This seems like a similar problem to what you have here
<emeyer> …You want to be able to specify all the gaps individually, or be able to repeat them
<emeyer> kbabbitt: We do have a repeat pattern defined in the syntax
<emeyer> fantasai: I think I need to read the proposed syntax a little more closely
<astearns> `gap-rule: 1px solid red, 2px solid red [2/2/4/4] 2px dashed silver, 2px dashed gray`
<fantasai> fantasai: Maybe we can have an example?
<emeyer> astearns: Is this representative?
<emeyer> kbabbitt: Yes
<fantasai> kbabbitt: in that example you'd have 1px / 2px alternating across the grid, and then alternating silver and gray in the other section
<emeyer> …In that example, you’d alternate 1px/2px for most of a grid, but within that potrtion of the grid you’d alternate silver and gray
<emeyer> …That would be in a future version; the question here is whether we can use commans to separate portions of the grid
<emeyer> astearns: If I understand, I think in order to more closely follow border-radius, we should use commas to separate values within…
<emeyer> fantasai: border-radius doesn’t use commas, so may not be a good analogy
<fantasai> border-radius: <length-percentage [0,∞]>{1,4} [ / <length-percentage [0,∞]>{1,4} ]?
<kbabbitt> border-radius: 2em 1em 4em / 0.5em 3em;
<emeyer> fantasai: The slash in border-radius separates the X side and Y side
<emeyer> …I don’t know how applicable this is to gaps
<emeyer> …You usually want to set border and color as a set
<emeyer> …Useage patterns may not be the same
<emeyer> kbabbitt: I got feedback that caused me to raise the issue
<emeyer> fantasai: We could separate regions with commas, but I think it might be confusing
<astearns> q?
<emeyer> …Then again we do use commas to separate lists of things, so following that pattern is a good thing
<emeyer> astearns: I think I’m good with the current proposed PR, not as sure about the extension
<emeyer> kbabbitt: The PR was written assuming extensions will be needed
<emeyer> …Another thing I raised was that we don’t need a separator within a given region
<emeyer> fantasai: But then you have to fix the order of them, and everywhere else we do line styling you can mix the order of width, style, color
<emeyer> …I don’t think we can just use spaces
<emeyer> …Commas is probably the best we can do here and we’ll have to get creative with region styling
<emeyer> astearns: Even if we use something other than commas, commas might still not be right for the extension
<emeyer> …I’µ good with commas and not concerned about being backed into a corner
<emeyer> astearns: Proposed resolution is to accept PR
<emeyer> TabAtkins: I have a tiny technical nit about the grammar but not germane to this issue
<astearns> RESOLVED: accept the PR to solve this issue