-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-gaps-1] Grammar for expanded column-rule shorthand #11496
Comments
@fantasai Brainstorming help requested here. So, we've got Naively, our normal way of spelling that is a comma-separated list, aka 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 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. |
I found this issue while looking for discussions to figure out how to serialize Anyway, I thought something like .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 |
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:
Agenda+ to resolve on that. |
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:
The expanded column-rule property grammar I currently have drafted in Gaps 1 is:
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:
@tabatkins:
I wanted to get more input on this topic. I can see a few different options:
decoration()
where the grammar inside the parenthesis takes at most one value or repeater for each of width/style/colorWhat do folks think?
The text was updated successfully, but these errors were encountered: