- From: David DeSandro via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Apr 2024 16:34:00 +0000
- To: public-css-archive@w3.org
Hi! Author of the [Masonry JS library](https://masonry.desandro.com) here 👋 . I am stoked to see Jen and the WebKit team prioritize making Masonry a first-class citizen in the browser. My heart-felt gratitude ❤️ ## Custom track sizing vs uniform column width In my experience, the vast majority of users want uniform column width. CSS grids provide _so_ much power over layout with track sizing. I think that amount of customization over the tracks is an unwanted feature when working with masonry layouts. Typically with a masonry layout, you want the item to have the same size regardless of its position in the grid. So, if you want to be practical, go with `display: masonry`, this will satisfy 95% of masonry layout usage. ## "display: masonry" vs "grid-template-rows: masonry" Having said that, `grid-template-rows: masonry` maps to my mental model of how Masonry works, now that CSS grid is an established convention. Personally, I'd like to see "masonry" used as the value name, as it's the convention with 14 years of history. I could also go with `grid-template-rows: collapse`, as it describes the behavior better. ## Follow-up issues Here are some issues that I know will come up. I don't think they need to be solved in this spec/implementation. But they are worth thinking about during this concepting phase. ### Loading images Day 2 issue for implementing a Masonry layout is dealing with shifting layout caused by loading images. With a masonry layout, the problem is exacerbated as taller cell element causes subsequent cells elements to move to a different column. The issue is best address by setting `aspect-ratio` or better yet `width` and `height` attributes on the `<img>`. I'd say it's outside the scope of this proposal to solve for unloaded images in the spec. But, the issue should be addressed in documentation. ### Expanding cells and maintaining position @chrisarmstrong mentions above: > One thing we've discovered over the past 10 years has been the importance of being able to intuitively predict how a masonry grid will re-flow when content is added to or rearranged within it. The classic [Masonry layout will shift a newly expanded cell element](https://masonry.desandro.com/methods#layout-masonry) to the next possible position https://github.com/w3c/csswg-drafts/assets/85566/ce4a8746-d2a1-4fc9-8e96-f069e50870c2 But users just want the item to open up where they clicked it. I actually had to build a separate layout library, [Packery, with a bin packing algorithm](https://packery.metafizzy.co/methods#fit) to solve for it https://github.com/w3c/csswg-drafts/assets/85566/4bea6f9f-abff-480d-ad50-195c0bfcb09f Maybe something like `grid-row: maintain` could address this ### Keeping horizontal order with a masonry layout A good amount of people requested that Masonry have more leeway in its layout algorithm so that horizontal order could be maintained. I eventually added a [`horizontalOrder` option to Masonry](https://masonry.desandro.com/options#horizontalorder).  --- Thrilled to see this work. I'll be following this thread merrily. -- GitHub Notification of comment by desandro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2070148836 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 22 April 2024 16:34:01 UTC