- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2024 13:35:30 +0000
- To: public-css-archive@w3.org
@alisonmaher A few quick points: > 2. [...] This is significant implementation-wise because determining alignment in the masonry axis will require a separate set of data structures to compute the running positions and perform layout than is needed in Grid today. > > 3. Given points 1 and 2 above, the implementation of Masonry within the Grid Module will require large chunks of divergences in code, which helps indicate to us that Masonry makes more sense as its own display type. How you split up your code and how we split up `display` do not need to match (and in many cases don't). That's an implementation detail. Whether we go with "masonry in grid" or "masonry as separate display type", an implementation could choose to share the implementation in their GridFormattingContext module or split out into separate GridFC/MasonryFC modules. This isn't something that should play into our decision here, which should be guided by what's the best interface for authors. > 5. There is at least one feature in Grid that doesn't make sense in Masonry (grid-template-areas) and one feature in Masonry that doesn't make sense in Grid (masonry-auto-flow). This is true, but I think those two properties aren't it. :) `grid-auto-rows/columns` and `masonry-threshold` are the two properties that don't cross over; `grid-template-areas` works fine and is usable in Masonry, and there's an issue open (https://github.com/w3c/csswg-drafts/issues/10231) on merging `masonry-auto-flow` and `grid-auto-flow` which may make that point moot. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2074967732 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 24 April 2024 13:35:31 UTC