- From: Ethan Jimenez via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Dec 2023 03:22:15 +0000
- To: public-css-archive@w3.org
Following @bfgeek comment, masonry is very straightforward in how to compute the containing block for items and works fine for its use case of "measure first, place later". One of the tricky cases I was evaluating for masonry is having orthogonal items: * The intrinsic size of an orthogonal item in the *grid axis* might rely on its available size in the *masonry axis*, but the masonry spec is very clear that the available size in the masonry axis is taken from the container size, then its contribution size is independent of its placement (or *stable* as Ian commented). * On the other hand, [the grid spec](https://drafts.csswg.org/css-grid-2/#grid-item-sizing) states that the grid area where a grid item is placed determines its containing block. This affects both, the proposed intrinsic `auto-fill` behavior and the track sizing algorithm for the *grid axis*. Also, should the intrinsic `auto-fill` consider what happens if the track sizing algorithm triggers [a second pass](https://drafts.csswg.org/css-grid-2/#algo-grid-sizing)? I believe that many concepts from grid are applicable and much simpler when ported to masonry, but some are probably not going to work because placement needs to happen at different points in the algorithm for grid and masonry. -- GitHub Notification of comment by ethanjv Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9321#issuecomment-1849263196 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 11 December 2023 03:22:17 UTC