[css-align][css-grid][css-flexbox][css-multicol][css-tables] A proposal for a Gap Decorations feature

[MatsPalmgren]

This is a concrete proposal for a gap decorations feature that covers the use cases and ideas discussed in the issues #2748 and #5080. (I've made a prototype implementation of this in Gecko to ensure it's feasible to implement.)

I'd appreciate any feedback you might have on this proposal in this issue. Thank you.

[rachelandrew]

After a quick read I'm generally a fan of this, it's a feature I know people really want in grid in particular. As mentioned in my comment on #6746 however, I'd like to see this specced along with block dimension overflow for multicol, which I'd like to do in Level 2 of the spec. I think from an author standpoint, the resulting column rows would be where the row gap would be expected. It's also possible to style spanners already with borders and margins whereas it won't be possible to style the gap between rows of column boxes.

[SebastianZ]

Thank you again for the detailed proposal for gap decorations, @MatsPalmgren! I really love to see this feature getting traction.

I've read through the specification now and I wrote down all the things that came to my mind while reading. Some points are bigger, others smaller. Some are very general, some very specific and some are asking for clarification. I tried to group the points to make it a bit easier to go through them.

General

1. In regard of the complexity and scope of the proposal, I believe it deserves its own spec. instead of being added to Box Alignment.
2. Whenever referring to an image's measurements, this should be done by using width and height, or x and y, as they are not flow-relative.

Specifications

1. Percentages on column-rule-image-slice should be defined as relative to the height of the image, and on row-rule-image-slice relative to the width of the image.
2. Depending on the outcome of [css-borders] accept "px" for pixel values in border-image-slice #6739 the syntax for column-rule-image-slice and row-rule-image-slice should be extended accordingly.
3. I think we concluded previously that defining an inset is better than an explicit length. So column-rule-length and row-rule-length should be removed together with the auto value of longitudinal insets properties.
4. The functionality of the lateral inset properties in combination with the rule width is rather complicated, in my opinion. I'd rather introduce *-rule-position properties similar to background-position that are independent of the rule's width and define the alignment plus an offset within the rule containing rectangle in lateral axis. They'd then have a syntax like [ [ start | center | end ]? <length-percentage>? ]!.
5. With the removal of the lateral inset properties, the word 'longitudinal' could be removed from the longitudinal inset property names. Besides then being unnecessary, it's a relatively long and complicated word.
6. column-rule and row-rule should include <'column-rule-image'> resp. <'row-rule-image'>. We missed to add <border-image'> to the border shorthand. We should do better here.
7. Regarding issue 1, I tend to say yes, we should add rule-* shorthands. And those should use the slash like the grid shorthands.
8. Again some name bikeshedding, though I'd name the values for the rule alignment properties gap-start, gap-center, gap-end, rule-start, rule-center, and rule-end. Also, *-rule-align can be a bit misleading because they are actually influencing the size of the rule not aligning it. So they probably should have another name. I can't come up with a good one right now, though.
9. The functionality of the longitudinal inset properties might also be combined with the one of the *-rule-align properties.
10. In addition to the above, I'd say, they should default to use what's defined for *-rule-align to ensure symmetry, i.e. an auto value. Alternatively, this could be handled by adding shorthand that combines the *-rule-align and *-rule-edge-align properties that applies gap, gap-center, or gap-over to all of them when set.
11. Regarding issue 2, I believe there should be padding-related options.
12. Regarding issue 3, I'm definitely for a separate all keyword. It might even default to the most common one of the four values it can be combined with, so that you can use it alone.
13. I also question whether all the different ways to style the extent are needed. For example, the results of column-rule-extent: short or long in masonry layout as illustrated with those big gaps look weird to me. Though that's just me. Maybe there are use cases for that I don't see.
14. Regarding issue 5, I strongly believe that should be possible. The examples look compelling to me and I think that's something authors would expect as the normal behavior. Related to this, I think the terminology is a bit mixed up here. I think you meant intersecting 'grid cell spans' instead of 'tracks'. Also, that seems to apply to normal grid layout as well.
15. Related to the above, it confuses me a bit that example 9 and the paragraph above it say that rules are also drawn between empty grid cells. Though in issue 5 they don't. In my opinion, rules should not be drawn between empty cells by default but there should be a way to control that.
16. I'd really, really love if all those properties also applied to table layout, though as far as I heard from implementers (I think also Mozilla in the past), they are reluctant extending their table layout mechanisms. This could have changed in the meantime and I might be wrong here, though if that's the case, gap decorations also applying to table layout should be moved to level 2 of the spec. in order to get this feature quickly into UAs.

Editorial / questions

1. column-rule-width is missing <line-width> as value.
2. There should be a note after the definition of column-rule-width and row-rule-width regarding the handling of the auto value.
3. It's not clear to me yet how *-rule-edge-align are meant to work. At the edges of a container there is no gap. Does it work like column-rule-inset suggested by @fantasai and @mirisuzanne by assuming a gap?
4. It's not clear to me what is meant by the 'start-most' and 'end-most' track in the definition of the start and end values of the *-rule-extent properties in grid containers.
5. The rule painting order specifies that rules are painted above an element's border, though in example 21 the column rule is painted below the border in the upper element and both are painted below the border in the lower element.

You see, I tried to provide detailed feedback. That's why the list may seem be a bit overwhelming. Though I hope it still helps the discussion and to push the spec. forward.

Sebastian

[MatsPalmgren]

@SebastianZ Thanks for your detailed feedback - much appreciated! I'll reply inline below:

1. In regard of the complexity and scope of the proposal, I believe it deserves its own spec. instead of being added to Box Alignment.

I don't have an opinion on that - I'll leave it for the CSSWG to decide.

2. Whenever referring to an image's measurements, this should be done by using width and height, or x and y, as they are not flow-relative.

If you're referring to the row/column-rule-image-slice properties specifically: I believe the spec is correct, although it might be a bit confusing that the spec talks about the block axis for column-rule-image-slice and then, at the end, says that "row-rule-image-slice works the same but in the inline axis", when the axis we describe in both cases is the rule's longitudinal axis! I've changed that so hopefully the intention is a bit clearer now.

1. Percentages on `column-rule-image-slice` should be defined as relative to the height of the image, and on `row-rule-image-slice` relative to the width of the image.

Again, the slicing is always done in the rule's longitudinal axis, so it's neither flow-relative, nor physical. I've changed it to refer to the image size in the longitudinal axis instead.

2. Depending on the outcome of [[css-backgrounds] accept "px" for pixel values in border-image-slice #6739](https://github.com/w3c/csswg-drafts/issues/6739) the syntax for `column-rule-image-slice` and `row-rule-image-slice` should be extended accordingly.

Thanks for the heads up. We can add that after it's added to the css-backgrounds spec.

3. I think we concluded previously that defining an inset is better than an explicit length. So `column-rule-length` and `row-rule-length` should be removed together with the `auto` value of longitudinal insets properties.
4. The functionality of the lateral inset properties in combination with the rule width is rather complicated, in my opinion. I'd rather introduce `*-rule-position` properties similar to `background-position` that are independent of the rule's width and define the alignment plus an offset within the rule containing rectangle in lateral axis. They'd then have a syntax like `[ [ start | center | end ]? <length-percentage>? ]!`.
5. With the removal of the lateral inset properties, the word 'longitudinal' could be removed from the longitudinal inset property names. Besides then being unnecessary, it's a relatively long and complicated word.

I honestly think that the model I propose is simpler than specifying both an alignment and an offset relative to that anchor point. What you suggest is basically just merging the *-inset-start/end properties into one property with a more complicated set of values instead.

It seems easier to learn a sizing model that we already use in other places in CSS, for example the left/width/right properties for abs.pos. or even margin-start/width/margin-end for block layout etc are very similar to the triplet of inset-start/column-width/inset-end I propose.

I also use the same model is used in both axes -- it's completely symmetrical.

I also think it's more expressive -- without lateral inset properties you have to resort to column-rule-width: calc(100% - <inset>) in some cases, which seems more complicated to me.

I agree the word 'longitudinal' is a rather long though... I discussed this with @dholbert , but we couldn't think of a better replacement for lateral/longitudinal.

Again, I think the sizing model I propose is simpler for two reasons:

1. it's similar to existing sizing models in CSS
2. it works the same way in both axes

I think this will make it easier for authors to learn than having a separate model for each axis.

I've added more examples to these sections in an attempt to make it a bit more pedagogical... I suspect that any perceived complexity is likely just that the spec doesn't explain it in a pedagogical way, but that's something we can fix hopefully.

6. `column-rule` and `row-rule` should include `<'column-rule-image'>` resp. `<'row-rule-image'>`. 

If we add px values to *-rule-image-slice then column-rule: 10px is ambiguous since it could also be a <line-width>. We would have to be very careful with any future changes to the longhand values to avoid ambiguities, so I'm not sure it's worth it... I'm leaning towards not including them...

8. [...] I'd name the values for the rule alignment properties `gap-start`, `gap-center`, `gap-end`, `rule-start`, `rule-center`, and `rule-end`.

That would be rather confusing since start/end typically refer to the logical sides of an axis. So does gap-start refer to the nearest edge of the gap or does it refer to the gap edge closest to the start of the axis? (which can be different edges)

I note that @fantasai /@mirisuzanne used the words nearest/farthest... I guess gap-near/gap-far would be an alternative to gap/gap-over that I use.

I'll stick to gap/gap-over for now - they're short and reasonably clear IMO.

Also, `*-rule-align` can be a bit misleading because they are actually influencing the size of the rule not aligning it. So they probably should have another name.

We already have for example align-self:stretch that also affect the size, so I don't see that as a problem.

9. The functionality of the longitudinal inset properties might also be combined with the one of the `*-rule-align` properties.
10. In addition to the above, I'd say, they should default to use what's defined for `*-rule-align` to ensure symmetry, i.e. an `auto` value. Alternatively, this could  be handled by adding shorthand that combines the `*-rule-align` and `*-rule-edge-align` properties that applies `gap`, `gap-center`, or `gap-over` to all of them when set.

I think it's simpler to have separate properties for separate concerns. I also suspect that combining them would make it less expressive.

13. I also question whether all the different ways to style the extent are needed.

That's fair. I don't know what's useful to authors so I basically just added all possibilities :-)

16. [...] I heard from implementers (I think also Mozilla in the past), they are reluctant extending their table layout mechanisms.

Right, but what we're concerned about are changes to table layout. This feature does not affect layout at all, it's purely an addition to the painting phase, so it isn't a big deal to support tables IMO.

Editorial / questions

1. `column-rule-width` is missing `<line-width>` as value.

That's intentional, column-rule-width is an existing property so this spec defines an extension (hence "New values"), so existing values are not listed.

2. There should be a note after the definition of `column-rule-width` and `row-rule-width` regarding the handling of the `auto` value.

OK, I added a reference to the section about "resolving a rule’s position and size".

3. It's not clear to me yet how `*-rule-edge-align` are meant to work. At the edges of a container there is no gap.

If you have an explicit width/height that is larger than the tracks then you get spacing at the edges.
See for example space-around here: https://drafts.csswg.org/css-align-3/#distribution-values

4. It's not clear to me what is meant by the 'start-most' and 'end-most' track in the definition of the `start` and `end` values of the `*-rule-extent` properties in grid containers.

By "start-most" I meant the first track at the start of the axis. I changed it to use first/last instead - hopefully that's clear enough...

5. [...] in example 21 the column rule is painted below the border in the upper element 

No, it's a blue border that is semi-transparent, but you're right it's a bit hard to see. I've updated the example.

and both are painted below the border in the lower element.

No, that grid has overflow: hidden so the rules are clipped at the padding edge.
I've made the container's border dotted, hopefully that makes it a bit clearer.

Again, thanks for all the feedback!

(I've updated the draft spec.)

[Wolfeur]

I'm thinking if there shouldn't be some extra, more logical properties, like *-block-end is for *-bottom. I'm notably thinking about flexbox axes, which can change responsively.

Have column-* and row-* get a shortcut gap-* (I don't think this causes any issue with the current gap property, which can act as a shortcut itself for gap-* properties).

Add to that gap-main-* and gap-cross-* that would generally correspond to column-* and row-* except for flex-direction: column, where the axes swap.

[SebastianZ]

@Wolfeur wrote:

I'm thinking if there shouldn't be some extra, more logical properties, like *-block-end is for *-bottom. I'm notably thinking about flexbox axes, which can change responsively.

Please let's discuss adding logical properties for them in its own issue! The initial proposal is already huge and I suspect the introduction of logical properties may require some separate discussion.

Have column-* and row-* get a shortcut gap-* (I don't think this causes any issue with the current gap property, which can act as a shortcut itself for gap-* properties).

This was my initial proposal in issue #2748.

Add to that gap-main-* and gap-cross-* that would generally correspond to column-* and row-* except for flex-direction: column, where the axes swap.

I am against adding specific property names as aliases just for one type of layout they're used in, even when "column" and "row" may not make sense in some situations. Note that the properties introduced here are meant to apply to grid, flexbox, multi-column, and table layout.

Sebastian

[bcdewitt]

Hey all! I'm looking for the most up-to-date info on progress here. I see this issue hasn't been updated in about a year - is there a more appropriate place to look?