Re: [csswg-drafts] [css-grid] grid-gap is still taking up space when an element defined in grid-template-area is not on the page. (#5813)

> @SebastianZ Note I'm not proposing that algorithm, it's just my guess of what fantasai might have in mind.

And the expectations I posted were not an interpretation of fantasai's algorithm but what I'd expect as an author.

> > Tracks 2, 4, 6, and 8 should collapse.
> 
> 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)".

That's what I understood as well, though again, in the examples I thought of an author's perspective, not about the proposed algorithm.

> > Tracks 2 and 3 should collapse.
> 
> 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.

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.
But you both know the algorithm better than me, so maybe you can clarify why it's a bad idea to choose them afterwards.

> > If so, I wonder if this has any use cases and if this shouldn't be discussed separately, as the use cases outlined so far refer to zero-width tracks.
> 
> The original use case at the top of this issue is about having tracks for optional elements that may or might not exist. Thus `hide` is a much more straightforward way to achieve this.

I think I misunderstood `hide` initially. I thought it would be based on `auto` but disregard the track sizes. After re-reading, `hide` only targets completely empty tracks, so disregards any spanned-over tracks and zero-width logic. So it targets the use case outlined in the first comment.

> On the opposite, I'm still not super convinced that the complexity of `auto` is actually worth it. The only use case that I have seen is your spanning case, which it seems that could be addressed with a nested grid.

There are different ways to achieve this right now for my use case. Nesting grids, though that also requires nested DOM structures. Or `:has()` can be used with different `grid-template` definitions, which also solves the use case of comment 0. Both approaches are much more cumbersome to write than an `empty-tracks: auto`, especially if web compatibility allows to make this the default as suggested by @fantasai.

> > [repeat(8, min-content)
> > ](https://codepen.io/SebastianZ1983/pen/vYqrEJr)
> > Tracks and gaps should collapse so that the result is the same as if gap weren't set.
> 
> I think you are wrong here @SebastianZ. If you requested gaps, then we must put one at least between 5/6.

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.

> > [repeat(4, 100px min-content)](https://codepen.io/SebastianZ1983/pen/XWLYJZM)
> > Tracks 2, 4, 6, and 8 should collapse.
> 
> 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.

So if item D is wider than track 7, tracks 6 and 8 are non-zero-width, and therefore don't collapse.

> > [200px 1fr 1fr repeat(5, 100px) with restricted container width](https://codepen.io/SebastianZ1983/pen/ExBRadw)
> > Tracks 2 and 3 should collapse.
> 
> I agree strongly with @Loirooriol that we should not make track collapsing depend on the available space. If nothing else, it creates a discontinuity.

I'd argue that this is similar to the `min-content` cases, at least in my understanding of how the algorithm could handle this.

Though I get your point about discontinuity, as tracks may collapse or not depending on the available space.

Sebastian

-- 
GitHub Notification of comment by SebastianZ
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5813#issuecomment-2314771588 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 28 August 2024 09:11:50 UTC