- From: Alison Maher via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Apr 2024 15:54:42 +0000
- To: public-css-archive@w3.org
> 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. Sure, this is an implementation detail. However, the implementation details we called out are a direct reflection of how the spec for Masonry is designed today. If we are having to diverge on very core aspects of an algorithm, the point still stands that this is a good indication that they are distinct enough concepts to separate (whether or not there are other concepts we can reuse between the two). > This isn't something that should play into our decision here, which should be guided by what's the best interface for authors. Implementability should be discussed when the implementation is derived from the algorithm outlined in a spec. And the performance implications in particular would have a direct impact on authors/end users. > 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. Gotcha, yeah these might be the right properties to be discussing, and I'm glad to hear it is something we are looking into. However, given that that issue is not resolved, it is still valid point to consider when discussing the larger question at hand in this issue. -- GitHub Notification of comment by alisonmaher Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2075284057 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 15:54:43 UTC