[css-grid] grid-gap is still taking up space when an element defined in grid-template-area is not on the page.

[bramdoppen]

Hi all! Love the work you do, but there is one thing that I would like to mention here: grid-gaps that are still taking up space when element is not in the DOM.

It works when all elements are present
Everything is fine here. Nice gaps between elements.

The issue:
When the last element (the filter) is removed from the page (but is still defined in the grid-template-area) the row-gap is still taking up space.

Would be great if css grid would not add those row-gaps in the future.
Did some research but there is no rock-solid workaround that I can use right now, or am I missing something?

[SebastianZ]

What you can do right now is define your grid differently when one of the elements is not in the DOM or not displayed.

In your example this means to only specify the "picture" and "content" areas and only two grid-template-rows.

Another solution for this would be allowing to define different gap sizes as discussed in #1659.

Besides those two approaches, I think a general solution for this would be to have a way to control whether to collapse gaps adjacent to empty grid tracks - something like a gap-collapse property with the values none and adjacent.

Sebastian

[fantasai]

I suspect we can't do it by default at this point anymore, but collapsing gaps seems like a good way to go here. We kinda do it already for auto-fit repeats. Might make more sense to take the same values as border-collapse though. :)

@MatsPalmgren Thoughts?

[bramdoppen]

@SebastianZ Thanks for your reply!

Allowing to define different gap sizes would be awesome, but it would not be a perfect solution for this issue.

Something like a gap-collapse property would solve this issue and it will be a gread addition to grid!

[pavelspichonak]

@bramdoppen maybe you found some new workaround? To have multiple css classes with different grid-template-areas when you have a lot of blocks and any block can be removed from page, it is a pain.

[bramus]

Collapsing gaps came up again today, where an author added position: absolute to empty grid cells to achieve exactly that (demo).

Would be nice if there was a property to control this, as already hinted above by @bramdoppen.

[bramdoppen]

@bramus Thanks for bringing this to my attention again. I'm blown away by the position: absolute; solution. Didn't thought that that would work.
But still, it would be nice if there was an option to control this. Any thoughts on this @fantasai @SebastianZ

[bramus]

@bramdoppen Adding display: none; to :empty cells also works, but it was pointed out to me that this can causes issues when you need it to be an aria-live region.

[SebastianZ]

But still, it would be nice if there was an option to control this. Any thoughts on this @fantasai @SebastianZ

Well, I already threw in my idea of a gap-collapse property. And it seems everyone here in this thread is positive about adding this feature. So I'll bring it to the agenda.

Sebastian

[Loirooriol]

In this thread I just see references to collapsing gaps, but the current spec only has this concept for the gutters of a collapsed track.

It's not clear to me what this proposal would do if the track is defined to be e.g. 100px. I don't think it makes much sense to collapse gaps if the track won't end up being zero. But it gets tricky because e.g. an auto track sizing function may end up producing a 0px track, or something bigger, and we don't know until the end of the track sizing algorithm, but the track sizing algo needs to know which gutters are collapsing.

I guess it could be restricted to collapsing the gutters adjacent to empty tracks whose min track sizing function is either a fixed 0px or intrinsic, and whose max track sizing function is 0px or intrinsic but not auto.

But I think it would be simpler to reuse the existing concept, and instead of adding a feature to only collapse gutters, add a feature to collapse empty tracks (and the adjacent gutters will collapse too).

Like empty-tracks: collapse | auto, where collapse (or maybe hide to align with empty-cells?) would collapse all empty tracks, and auto would only collapse the empty tracks generated by an auto-fit repetition.

[SebastianZ]

In this thread I just see references to collapsing gaps, but the current spec only has this concept for the gutters of a collapsed track.

It's not clear to me what this proposal would do if the track is defined to be e.g. 100px. I don't think it makes much sense to collapse gaps if the track won't end up being zero.

I agree. That's what I meant when I wrote "have a way to control whether to collapse gaps adjacent to empty grid tracks" but that wording was obviously ambiguous.

But I think it would be simpler to reuse the existing concept, and instead of adding a feature to only collapse gutters, add a feature to collapse empty tracks (and the adjacent gutters will collapse too).

Like empty-tracks: collapse | auto, where collapse (or maybe hide to align with empty-cells?) would collapse all empty tracks, and auto would only collapse the empty tracks generated by an auto-fit repetition.

That probably covers a lot of use cases. Though I also have an example in which this wouldn't work:

In that widget, the image on the left spans across all grid rows, so they are not empty. The contents on the right are placed in individual grid cells. The rows are defined as 1fr repeat(4, min-content) 1fr. So one of the cells on the right is not filled. This gets obvious when a row-gap is added:

In this case, it would make sense to collapse the adjacent gaps plus the 0-width track to always keep the contents on the right vertically centered.

So the two cases, empty and 0-width should be controllable. Not sure whether they should be handled individually or together. Though I agree that this new feature should affect collapsing both tracks and gutters.

Sebastian

[fantasai]

I think this issue needs a more concrete proposal before it's useful to bring it up to the WG.