[css-gaps-1] Gap decorations next to empty grid areas

[kbabbitt]

We got some author feedback around unwanted gap decorations appearing next to empty grid areas. Examples:

---

MicrosoftEdge/MSEdgeExplainers#1099 - unwanted decorations in the empty space to the left of the content area:

---

MicrosoftEdge/MSEdgeExplainers#1100 - unwanted decoration in the top row, to the left of "Other things about me":

---

MicrosoftEdge/MSEdgeExplainers#1111 - live version https://codepen.io/bigandy/pen/vENxYzV - unwanted decorations after the last article:

---

For the first two cases, I suggested two options: Gap Decoration Areas to set different decorations for different sub-areas of the grid using grid lines, or a new property to define how gap decorations interact with empty grid areas, similar to how we have empty-cells for tables. In both of those two cases, the authors expressed a preference for Gap Decoration Areas.

The third case is more interesting. It's a responsive grid that re-flows the contained articles based on how wide the container is. I don't see how Gap Decoration Areas might solve the unwanted decorations in such a case, at least not without script to support. So I think this is a good use case for a property to control decorations in empty grid areas.

Perhaps that property is empty-cells, though I think in this case there would need to be three states: (1) decorations in all gaps; (2) decorations in gaps with an item on at least one side; (3) decorations in gaps with items on both sides. In offline discussion with @alisonmaher @oSamDavis @jav099 last week, it also came up that there may be cases where the author wants different behaviors in each direction.

[alisonmaher]

An additional thought is that this could be handled as a new value within rule-break. Similar to spanning-item we could break at empty-cell, which would allow the gap to break at empty cells. This would limit you from combining the empty cell case with other kinds of break rules, though, and has less control over what an author wants to consider as "empty", so a separate property to control this would allow for more flexibility.

[kbabbitt]

In a call yesterday, @bfgeek pointed out that it might be useful for some scenarios to have a five-state value:

1. Paint regardless of content (current/default behavior)
2. Paint if there's content on at least 1 side
3. Paint if there's content on at least the start side
4. Paint if there's content on at least the end side
5. Paint if there's content on both sides

I'm struggling to come up with a good name for the property though.

This one I think has good words in the wrong order; CSS naming conventions lead to a misplaced modifier:

rule-adjacent-content-visibility: any | one-side | start-side | end-side | both-sides

More accurate but pulls the name away from related property names, though maybe that's okay given the precedent of empty-cells for tables?

adjacent-content-rule-visibility: any | one-side | start-side | end-side | both-sides

This reads slightly easier on the surface, but it sounds to me like it's specifying which sides need to be empty for behavior to change, which I think is a logical flip from what authors need:

rule-empty-area-visibility: any | one-side | start-side | end-side | both-sides

[alisonmaher]

I like the idea of starting with rule- so we could have properties for column-rule- and row-rule- in case an author wanted this to behave differently in each direction.

Another idea is something like rule-skip-empty-areas: none | one-side | start-side | end-side | both-sides

[css-meeting-bot]

The CSS Working Group just discussed [css-gaps-1] Gap decorations next to empty grid areas.

The full IRC log of that discussion

<fantasai> scribe+
<fantasai> kbabbitt: #1 feedback we got from authors so far is wanting more control over where gaps appear
<fantasai> kbabbitt: Layouts they wanted with unwanted decorations
<fantasai> kbabbitt: especially around empty areas
<fantasai> kbabbitt: Another example, they want the separators in second two rows, but no first
<fantasai> kbabbitt: Discussed different approaches
<fantasai> kbabbitt: one was to have a property similar to empty-cells
<fantasai> kbabbitt: another is concept of gap-decoration-areas, which was in original explainer but pushed out of Level 1
<fantasai> kbabbitt: in this case, you define an area based on grid syntax
<fantasai> kbabbitt: and override set of decorations for that area
<fantasai> kbabbitt: name the ara, refer to it in the gap decoration properties
<fantasai> kbabbitt: could define things for everything but the top, for example
<astearns> q+
<fantasai> kbabbitt: in both of these two cases, the authors did express preference for this over empty areas, but third example
<fantasai> kbabbitt: here is a responsive layout, where they have an outer grid and each headline article is a subgrid
<fantasai> kbabbitt: auto-fill grid, so as you size the window, columns reflow
<fantasai> kbabbitt: and you can't really identify the area
<fantasai> kbabbitt: so because of that, I'd like to solve with some sort of property to control decorations in empty areas
<fantasai> kbabbitt: some discussions about this, and I think the shape of it is a 5-state value to control where you want it
<fantasai> kbabbitt: current behavior is painting all the gaps
<fantasai> kbabbitt: might want to only paint if one side
<fantasai> kbabbitt: or only in left side or only one side or only both sides
<fantasai> kbabbitt: a few things to consider, one is what to name is
<fantasai> kbabbitt: another is do we want to do this
<fantasai> astearns: Would like to object to 1st solution where you define areas where rules apply
<fantasai> astearns: My concerns were, I like the fact that the syntax looks like grid-template-areas and has similar semantics
<fantasai> astearns: but I think it would get easily out of sync with template definition
<fantasai> astearns: and out of sync with what parts of the grid the content is actually flowing
<fantasai> astearns: You set up your rule areas expecting your content is in one place, but then change it, and forget to fix it up
<fantasai> astearns: so prefer dealing with empty areas directly
<astearns> ack astearns
<astearns> ack fantasai
<emilio> fantasai: same concern as astearns for the areas version, seemed a bit fragile
<emilio> ... A property on the items themselves sounds like a good idea
<emilio> ... if the default is draw all the lines and you have a bunch of empty areas
<emilio> ... you can't turn those off easily
<emilio> ... I think you'd want a grid level thing
<emilio> ... and then a grid item thing that allows you to override it
<SebastianZ> +1 to fantasai
<emilio> ... so certain elements you want rules around
<emilio> ... instead of associating to a position on the grid
<emilio> ... you associate it on the item
<alisonmaher> q+
<emilio> ... so the item decides based on the content around it
<emilio> q+
<astearns> wondering whether someone will implement a CSS-only game of life with this new feature
<emilio> ... and whether you want that unilaterally or only if the other item enables it
<emilio> ... I think you still want a default behavior on the grid
<emilio> kbabbitt: for the first example, I guess you'd turn it off on the grid and then turn it on for some items
<emilio> fantasai: correct
<oriol> q+
<emilio> ... and sometimes you want to make it visible in all adjacent places, or only if there's an item around
<SebastianZ> q+
<emilio> ... and you want some items to be able to ignore and so on
<emilio> kbabbitt: so two props, one for the global state
<emilio> ... is that an on-off on the grid?
<emilio> fantasai: I think you need at most 3 states
<emilio> astearns: let's not worry too much about the details, let's go through the queue
<astearns> ack alisonmaher
<emilio> alisonmaher: what if there's multiple items with conflicting instructions?
<astearns> q+
<emilio> fantasai: I think we want items to turn things on and whether their presence turns things on, but not suppressing lines
<astearns> ack emilio
<fantasai> fantasai: So an item could say "I want a line" or "I want a line if someone else wants a line"
<fantasai> fantasai: But can't turn it off
<JoshT> q+ turning on decs for specific cells
<astearns> ack turning
<Zakim> turning, you wanted to comment on decs for specific cells
<astearns> ack on
<astearns> ack the
<astearns> ack on
<emilio> emilio: was going to raise the same kind of concern
<astearns> ack the
<emilio> ... would like to not allow for weird conflicts
<astearns> q+ JoshT
<emilio> kbabbitt: I think that model makes sense to me
<astearns> ack oriol
<emilio> oriol: My question was about the 'whether there's content or not'
<emilio> ... do we care about absposes? Those are not technically a grid item
<astearns> ack SebastianZ
<emilio> fantasai: those don't count, if you are doing that you need to turn the lines unilaterally
<emilio> astearns: re. fantasai suggestion, there's no way to turn on things for empty areas
<emilio> ... because you can't target
<emilio> fantasai: seems unlikely you'd want something like that where you want specific empty areas
<emilio> s/astearns:/SebastianZ:/
<fantasai> s/empty areas/empty areas to have grid lines, but the rest of the grid to not/
<emilio> fantasai: if you want to turn them on on a particular area you can put an empty div there or a subgrid
<astearns> ack JoshT
<emilio> JoshT: Coming back to the question around being more precise about where the decorations go
<emilio> ... was talking to kevin about a potential use case we might have where you might have a grid, you don't want to show the lines above a cell that doesn't have an image on it?
<emilio> ... I wonder if we should still consider that kind of use case
<emilio> fantasai: can you review that example?
<emilio> JoshT: let me share my screen
<emilio> ... [shows bbc.cok.uk]
<emilio> ... we use border lines for dividers for things that don't have an image
<emilio> fantasai: is the layout that you have there such that you only have that row or they overlap?
<emilio> JoshT: they overlap and in this case it might be better to use border
<emilio> ... but there might be similar cases
<emilio> kbabbitt: is that something that you could do targetting elements that don't have an image?
<emilio> JoshT: I think so
<emilio> kbabbitt: then in this case you'd target non-image cards
<emilio> ... and turn the decorations on there
<SebastianZ> q+
<emilio> astearns: but if you can target them why would we need this extra proposal?
<emilio> astearns: I think what there's in the spec now allows to do this
<emilio> kbabbitt: no it's not, but with fantasai's proposal we would be able to do this
<emilio> astearns: I wanted to ask whether we were discussing this because this needs to be part of the first version of gap-decorations
<emilio> ... you're pulling it back in after pushing it off
<emilio> kbabbitt: What I pushed off was the grid areas version
<emilio> ... so this is more about solving some of these cases
<astearns> ack astearns
<emilio> ... the empty areas here I'd like to explore more
<emilio> ... because it's part of the feedback that we're receiving
<fantasai> rule-visibility-items: always | adjacent | between
<fantasai> rule-visibility-self: auto | always | between
<fantasai> s/adjacent/around/
<emilio> q?
<astearns> ack SebastianZ
<emilio> SebastianZ: maybe JoshT could share screen again?
<fantasai> rule-visibility-items: all | around | between
<fantasai> rule-visibility-self: auto | around | between
<emilio> ... I think the bbc use case is not completely covered by this thing
<emilio> ... you have an image aligned with the top line
<emilio> ... I guess you'd use border line
<fantasai> emilio: fact that it's aligned with top of border is an artifact of using border
<emilio> ... with gap decorations you wouldn't be able to achieve exactly that
<fantasai> s/.../sebastianz/
<emilio> fantasai: if you didn't have that alignment it'd be weird, that's why border would be the right tool here
<emilio> ... my proposal is above, `rule-visibility-items`
<emilio> ... `all` would be all borders
<emilio> ... `around` is for all the cells around each items
<emilio> q+
<emilio> ... `between` would be only if there's an adjacent item
<emilio> ... `rule-visibility-self` `auto` does whatever the grid container says
<emilio> ... the other values behave as expected
<emilio> kbabbitt: I like that, also like how they're named around the grid alignment properties
<oriol> q+
<emilio> fantasai: yeah and if we need extra control like per side you can split `rule-visibility-self` per side
<oSamDavis> q+
<emilio> SebastianZ: So you'd have `column/row-visibility-items` and `row-*`?
<emilio> fantasai: first q is whether we need that control
<emilio> ... but it'd be an easy extension
<astearns> ack emilio
<fantasai> emilio: sounds good, but the items naming makes it sound like it will only put rules around the items, maybe use 'cells' or something
<fantasai> emilio: but otherwise seems like a reasonable start, and easy to extend
<fantasai> SebastianZ: but if you have a spanning item, you won't have it between those cells
<astearns> ack oriol
<fantasai> fantasai: I think consistency with the alignment properties is probably more important
<astearns> ack oSamDavis
<fantasai> oriol: What if there was one item and then a spanner that spanned over it, would there be a rule underneath the spanner?
<fantasai> fantasai: Not unless there would be one otherwise, I think.
<fantasai> oSamDavis: Would it affect layout?
<fantasai> kbabbitt: No, all it does is turn decorations on/off in certain places
<fantasai> astearns: Sounds like you have an outline of how to design this feature, so maybe take it and run with it and bring it back to us :)

[oSamDavis]

The consensus from the F2F discussions was to move away from an area-based definition (gap-decoration-areas) and toward a property-based solution for controlling gap decoration visibility. This approach involved a combination of container-level and item-level properties.

Based on feedback from developer trials, the primary use cases we've seen can be fully addressed with a container-level control. Therefore, we propose having container-level control for Level 1 and suggest deferring item-level controls to a future version of the spec, pending further use cases.

Proposed Solution for Level 1

We propose introducing a set of container-level properties to control the visibility of gap decorations relative to grid items.
[credit to @kbabbitt for design]

/* Longhands */
column-rule-visibility-items: [ all | around | between | none ];
row-rule-visibility-items: [ all | around | between | none ];

/* Shorthand */
rule-visibility-items: <'column-rule-visibility'> || <'row-rule-visibility'>;

Property Value Definitions:

• all: The default behavior. Decorations are painted in all gap segments, regardless of whether adjacent grid cells are occupied.
• around: A decoration is painted in a gap segment if at least one of the two grid cells adjacent to it contains a grid item.
• between: A decoration is painted in a gap segment only if both of the grid cells adjacent to it contain a grid item.
• none: No decorations are painted.

This approach directly solves the primary feedback from authors who wish to hide separators around empty areas of their layouts.

Interaction with Other Layout Modes Outside Grid

To the best of my knowledge this concept of "empty cells" is specific to Grid. Other layout modes like Flexbox, multicol, and masonry do not have a formal grid structure with cells that can be definitively identified as "empty". Therefore, these properties would only apply to grid containers and would have no effect on other layout contexts.