-
Notifications
You must be signed in to change notification settings - Fork 688
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-grid] grid-gap is still taking up space when an element defined in grid-template-area is not on the page. #5813
Comments
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 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 Sebastian |
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 @MatsPalmgren Thoughts? |
@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 |
@bramdoppen maybe you found some new workaround? To have multiple css classes with different |
Collapsing gaps came up again today, where an author added Would be nice if there was a property to control this, as already hinted above by @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. |
@bramdoppen Adding |
Well, I already threw in my idea of a Sebastian |
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. I guess it could be restricted to collapsing the gutters adjacent to empty tracks whose min track sizing function is either a fixed 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 |
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.
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 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 |
I think this issue needs a more concrete proposal before it's useful to bring it up to the WG. |
My proposal in #5813 (comment) is quite concrete: just add a property that controls whether empty tracks should collapse. The concept of collapsing a track is already defined in the spec, so no need to invent anything complicated. I think it's fine that it doesn't cover Sebastian's testcase, since that would probably be better addressed with a nested grid anyways. |
Would be amazing to make some progress on this. I've found it really difficult to use CSS grid for complex layouts with optional slots because the gaps between columns/rows do not collapse when the adjacent column/row is otherwise unused. Usually we have to go back to using manual margins on children so that when they are not there the gaps collapse, but this has other problems that were originally solved by gaps. Another solution is to not use grid at all and to use flex instead, but this requires additional DOM wrappers that can be hard to insert in the right places (especially with responsive layouts where children move to different slots depending on the screen size). What is missing for this to be discussed? I think the above proposal for |
Given that everybody is positive about adding this feature and @Loirooriol's proposal, I think we're in a good position to get a resolution on this. I think the main point for discussion is whether we can and should include the use case I previously outlined in the algorithm. Sebastian |
I am assuming this was not discussed in yesterday’s meeting? |
I think we should try for an Suggestion is values
For grid a track is empty if:
For masonry the track is empty if
@SebastianZ I think it makes sense to address the case you outlined with spanners; it doesn't seem unusual at all. To do that, we need to know which of the various tracks to collapse if all the spanned tracks are otherwise empty: do we prioritize keeping the first track? the largest track? the track with the most items (unless there's a tie, then what)? |
Do we need prioritization? I assumed, it would be sufficient to extend the track sizing algorithm to say that all spanned tracks that end up being zero-width will be collapsed. Sebastian |
@SebastianZ We need to know which tracks collapse before the track sizing algorithm (since the presence of gaps affects the result of the track sizing algorithm). |
What would be a best guest timeline on this being generally available across major browsers or through polyfills? This would allow for a truly flexible grid where all items could be optional and move independently |
@Loirooriol Right, but the track sizing algorithm is already run twice for row and column sizes in the grid sizing algorithm. So we could say that in steps 3 and 4 we base re-resolving the sizes and collapsing gaps on whether the tracks are zero-width at that point. @sir-captainmorgan21 This issue is still being discussed and there is no resolution yet. So it is way too early to predict when this will be available in any browser, let alone in all of them. Sebastian |
@SebastianZ I think I agree with @Loirooriol that we should determine which tracks to collapse before doing track sizing. I guess one solution would be that we keep the track(s) with the most items in it (i.e. keep both if there's a tie). I think that does a reasonable job of handling most spanning relationships? |
@fantasai I'm not sure if extra complexity of the
What exactly is "zero"? Just
Why is this needed?
I'm not sure if I follow. In @SebastianZ's example, not all of the spanned rows are otherwise (ignoring the image) empty. @SebastianZ I would prefer to avoid extra passes of the sizing algorithm. |
I am imagining only an extra step (which is necessary in any case we want to solve this), not an extra pass. And regarding "zero", I'd expect this to include any track that does not take up any space at that point, independent of whether that's Sebastian |
I think for simplicity, it might be best to just take zero lengths here.
Because in masonry layout, auto-placed items contribute sizing to every track.
Yes, but if they were otherwise empty, then we need to figure out what to do. |
If I understand it correctly, the proposal to handle spanning items, is that:
So for example, if item A spans tracks 1-5, item B spans tracks 1-5, item C spans tracks 3-7, and item D spans tracks 6-8
Then A,B,C mark tracks 3-5 as filled, and D marks tracks 6-7 as filled. So we collapse tracks 1-2 and 8. Is that right? |
@Loirooriol It's hard for me to imagine how the algorithm should work in that case given your example. Therefore, I've created a few Codepens using your example. Based on them, I'll describe what I'd expect regarding collapsing. Collection: https://codepen.io/collection/RzMBaZ
|
@SebastianZ Note I'm not proposing that algorithm, it's just my guess of what fantasai might have in mind.
I think fantasai's idea wouldn't collapse 4 as per "we keep the track(s) with the most items in it (i.e. keep both if there's a tie)".
Ditto for 3,5.
A priori we don't know if the 1fr will have any free space to grow, so this would need multiple passes of the track sizing algorithm, which I don't like.
The original use case at the top of this issue is about having tracks for optional elements that may or might not exist. Thus |
@Loirooriol Yes, that's a great example.
I think you are wrong here @SebastianZ. If you requested gaps, then we must put one at least between 5/6.
What if track 7 doesn't have enough space for item D? I think we would want to avoid automatically creating overflow, especially since the author's specified design avoids such overflow.
I agree strongly with @Loirooriol that we should not make track collapsing depend on the available space. If nothing else, it creates a discontinuity. Thanks @Loirooriol and @SebastianZ for all the examples. |
And the expectations I posted were not an interpretation of fantasai's algorithm but what I'd expect as an author.
That's what I understood as well, though again, in the examples I thought of an author's perspective, not about the proposed algorithm.
Again, not multiple passes. My suggestion was to choose the tracks to collapse after the first pass instead of before as suggested by you and fantasai. At that point we should know whether the 1fr resulted in zero-width tracks.
I think I misunderstood
There are different ways to achieve this right now for my use case. Nesting grids, though that also requires nested DOM structures. Or
Based on your algorithm, yes. Based on author intention, it's unclear. Though I'd also note that a grid with only spanning items which overlap in several tracks, is an edge case.
So if item D is wider than track 7, tracks 6 and 8 are non-zero-width, and therefore don't collapse.
I'd argue that this is similar to the Though I get your point about discontinuity, as tracks may collapse or not depending on the available space. Sebastian |
So, to summarize where we are right now:
Sebastian |
Consider a grid with two Currently, the algorithm will size the 1st column tightly around the 1st item, and the remaining size of the 2nd item will be accommodated by the 2nd column. With fantasai's proposal of spanning items and Even if
Steps 3 and 4 are only needed when there are things like aspect ratios or orthogonal flows, with this they would need to run more frequently. |
My proposal to move this forward is just adding This should address the original usecase, and be simple to spec and implement (since we are already doing that for Then open other issue(s) about new value(s) to only collapse when the track would be guaranteed to be 0px, and to consider tracks containing spanning items as empty in some cases. |
Is this worth adding to the agenda? I'd quite like to see this progress. |
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?
The text was updated successfully, but these errors were encountered: