- From: Michael via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 May 2024 15:52:20 +0000
- To: public-css-archive@w3.org
Yeah, I think upon reflection, I'm adding a +1 to the `display: masonry` side of this debate. There are too many edge cases like what happens if both columns and rows are declared as `masonry`, what happens if we do a `grid-row: span 2`, how could we support `grid-template-columns: repeat(auto-fill, auto)` which would only be valid in a masonry context, etc etc. And a lot of the extra properties wouldn't work outside of a masonry context, like `align-tracks`, `justify-tracks` and `masonry-auto-flow`. Someone new to CSS grid would find all of this quite confusing. To me, it would feel almost like a kitchen sink layout methodology if this went through, cramming what is essentially two different layout methods into one. And I worry about the performance implications, and future maintainability of this too (a grid level 4 would have to not only consider normal grid layout + subgrid, but masonry too - in which there may be some things added to that spec that don't make sense for masonry). If this is kept separate, we can optimize the performance for that specific layout type, and future specs can be more focused on features for either normal grid or masonry. For my own personal use case, creating a grid with a fluid track definition, alignment options, direction options, and the ability to span an item over columns and/or rows would cover pretty much all my use cases. -- GitHub Notification of comment by michaeltugby0 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2122938276 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 May 2024 15:52:21 UTC