[csswg-drafts] [css-grid-3] Masonry - Intrinsic sizing of tracks & masonry-grid doesn't produce to good/desirable results. (#8206)

bfgeek has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-grid-3] Masonry - Intrinsic sizing of tracks & masonry-grid doesn't produce to good/desirable results.  ==
This is a somewhat meta issue surrounding the current definition of how intrinsic track sizing works, and the intrinsic sizing of the masonry grid.

As currently defined (https://drafts.csswg.org/css-grid-3/#track-sizing) the tracks that have `min-content`, `max-content`, `fit-content`, and `auto` don't work as they do in regular grid. For most of the tracks the content based tracks will resolve to zero, and the `auto` will result to `1fr`?

On top of this it means that an intrinsically sized masonry grid won't match developer expectations, e.g. `width: max-content` or similar (being a flex-item, grid-item, floating, etc, etc).
We currently have a similar issue for multi-line flexbox which we are trying to fix, but this is somewhat worse due to being the default.

There are multiple avenues to solving the above, however one would be make masonry its own display type with a reduced subset of allowable definitions for tracks.
Most masonry examples I've seen choose to size all the tracks the same size. An potential path forward would to allow repeats of "intrinsic" tracks where everything gets sizing as-if it was in one track, then decide how many tracks to insert.
On top of this you could additionally allow non-intrinsic tracks in combination with the repeater. E.g.
`masonry-tracks: 100px repeat(auto-fill, minmax(min-content, 100px));`

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8206 using your GitHub account


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

Received on Thursday, 8 December 2022 20:05:18 UTC