[css-gaps-1] Dropping decorations for suppressed gaps

[kbabbitt]

In #13663 (comment) we resolved that, when varying gap decorations are assigned to a wrapping flex container, decorations are assigned to gaps in "linear" fashion, such that the sequence continues from one flex line to the next. An open question from that discussion is what to do with the decoration that would have appeared next to the last item in a flex line. Does that decoration get dropped from the sequence, or does it get assigned to the first gap in the following line?

One use case @fantasai brought up was a toolbar with varying decorations to separate items into groups. I constructed a straw example here: https://codepen.io/kevinbcmu/pen/ogzdvgE

In my opinion, it's a little clunky to do this with gap decorations, because you have to keep your markup structure in sync with your decoration sequence. But I can't think of a better way to do it with the tools we currently have. I agree it's a case where dropping the decoration is what the author wants, and I haven't been able to come up with a plausible use case for not dropping it.

The other case where I think we'd want to drop a decoration is a gap suppressed due to fragmentation. Consider this example: https://codepen.io/kevinbcmu/pen/YPyYwBQ?editors=1100

There's an auto repeater to set up dashed decorations for the intermediate rows, followed by a single value to set up solid decorations in the last row gap. If this example were fragmented on that last row gap, the author would not want the solid decoration pushed up to the preceding gap.

A third case worth considering is gaps suppressed due to collapsed tracks in grid. I've considered this a bit but haven't yet been able to construct a use case that points in one direction or the other.

[mhochk]

As a (contrived, arguably bad) collapsed tracks in grid example, I can imagine implementing a menu like this one as a single grid.

Though not the approach I would recommend taking, I can imagine doing this with a hard-coded set of rows based on the maximum number of rows per section, and then using a gap decoration for the one dividing line.

Section Title Row - Pinned
10 auto-sized 'pinned item' rows (3 of which would be empty in the image above)
Section Title Row - Frequent
10 auto-sized 'frequent' rows (4 of which would be empty in the image above)
5 auto-sized 'core window' rows (2 of which would be empty in the image above)

And then row-rules to skip the first 22 rows, then make the 1 gray line, then skip the remaining rows.

If we wanted to support this kind of (questionable) design, it would require us taking the drop/skip approach.

[mhochk]

Slightly less contrived, but along the same route, I tossed together this codepen inspired by what a few of my stock/credit-card/bank sites look like.

https://codepen.io/mhochk/pen/YPGLrza

The first example shows what a lot of those sites show me - a collection of account-impacting items, grouped into "pending" and "posted/completed". The 2 groups almost visually match, but one of the groups shows an additional column. For this example I have them use the same style, and one just hide a column (though I don't think this is what the actual sites do).

The second example shows dynamically hiding a column in a similar fashion. Fidelity currently does a full reload when you hide a column like this, but there's no reason why it couldn't just be a minor style change.

[kbabbitt]

@mhochk I don't think that example shows collapsed grid tracks, unless I'm missing something - grid track collapsing is a behavior of auto-fit.

I tried constructing an example, though I admit it's pretty contrived and not what I would reach for: https://codepen.io/kevinbcmu/pen/MYjGpNa?editors=1100

If one of the "Widget N" rows is deleted, that row should collapse, and I think the expected behavior would be to retain the alternation rather than dropping a decoration such that you get two adjacent row rules of the same color.

[alisonmaher]

For flex, I agree that skipping the rule on wrap will likely be more common. However, I'm not convinced it necessarily should be the default (as opposed to an opt-in).

For example, in the following demo, you have an image gallery that guarantees two items per flex line with different % fills per line. Each row also alternates between images of different color hues, and you want to create a decoration repeat pattern to match the hue of the images in that row: https://codepen.io/alisonmaher/pen/raMvgwj.

If we skip style decorations by default, we will never render the second color in the repeat in this example, which could be confusing.

Regarding gap suppression in fragmentation, I do think we should skip because otherwise that would mean decoration styles would shift up when printing.

For grid collapsed tracks, we drop those tracks before tracks are finalized. I think they should be treated as not having gaps to begin with, and as such, we shouldn't skip decoration rules where they would have been.

[mhochk]

@kbabbitt - I agree that my expectation as a dev would be that the alternating pattern was maintained. I forked your codepen to make a very contrived example with explicit placement, but I would expect the same with your dynamic example and this one - that the alternating pattern is maintained.
https://codepen.io/mhochk/pen/KwgRLrM

[jav099]

Regarding flex wrap behavior, I am not entirely convinced that the more common use case would be "dropping". We should support it, but maybe as a toggle of some sort because otherwise it can lead to surprising and unintended behavior in a lot of common cases, where the author would be confused.

Different behavior depending on viewport (mobile vs desktop)

.flex {
  column-rule-color: repeat(auto, red blue);
}

Viewport A (desktop)

Viewport B, drop at wrap (mobile)

Viewport B , no drop at wrap (mobile)

Here is a more concrete example, but in general this dropping behavior could be surprising whenever an author wants a certain "theme" where one color of the theme can seemingly randomly disappear. They may think its a bug, and would be really difficult to debug why one color is not present at all, say on mobile. This seems like a pretty common use case to me.

.menu-section {
    display: flex;
    column-rule-color: repeat(auto, var(--bleu), var(--blanc), var(--rouge));
  }

Viewport A (desktop)

Viewport B, drop at wrap (mobile)

Viewport B, no drop at wrap (mobile)

In general I think the no drop at wrap model behavior follows the mental model of what a flexbox is more closely, which then doesn't lead to unexpected behavior which as a result can be hard for an author to debug, since intuitively it would probably not be the expected behavior. If the author is not intimately familiar with the gaps spec, it would seem like a bug to them that one color disappears in certain viewports.

[oSamDavis]

For flex wrapping, I do not think we should have the dropping behavior by default. This reasoning boils down to the same sentiment that motivated web authors choosing linear assignment in issue 13663: It's not immediately clear from the CSS what to expect if dropping is the default.

For example, in this self-contained component I created for a notification card:

 column-rule-style: solid, dotted;

If dropping were the default, there would be a solid line between Open and Preview and a dotted line between Preview and Remove, which doesn’t reflect the separation I want. I understand the need for dropping behavior when items shift and certain decorations need to stay with specific groups, but I don't think it should be the default.

For fragmented gaps, we should apply dropping behavior to maintain consistency when printing.