<story><title>Help us invent CSS Grid Level 3, a.k.a. &quot;Masonry&quot; layout</title><url>https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/</url></story><parent_chain><item><author>achairapart</author><text>So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when Firefox first proposed it.&lt;p&gt;The news here is that people at WebKit decided to push the debate to the public, inviting designers and developers to take some action (“post to social media, write blog posts”), in order to get past this.&lt;p&gt;While it may look just like a formality, I think this will make an important precedent. The real underling debate here is either to treat every layout option as a part of the CSS Grid, or keeping adding new CSS Display proprieties as necessary.&lt;p&gt;The first option will make even more complex the (already convulsed, IMHO) CSS Grid specs, the latter will bloat the CSS specs with a load of new proprieties (and related sub-proprieties).&lt;p&gt;Either way, it&amp;#x27;s not as easy as it looks.</text></item></parent_chain><comment><author>bfgeek</author><text>Part of the tension with building masonry on top of grid is that they work in fundamentally different ways.&lt;p&gt;Grid you place everything in the grid first (e.g. an item goes in col:2,row:3), then size the grid.
Masonry ideally you want to size the tracks first, then place items in those tracks.&lt;p&gt;The first Firefox implementation (and the spec at that stage) basically said you don&amp;#x27;t consider any masonry items for sizing tracks (except for the first row, and some other rules - its complex). This meant that it is trivial to create items that overflow their tracks.&lt;p&gt;The specification at the moment asks to place every item in every possible track. This has quadratic performance O(N_tracks * N_items) in the worst (and somewhat common case). Quadratic performance is bad[1] and we don&amp;#x27;t really have this in other layout algorithms.&lt;p&gt;With nesting introduced the performance goes (sub-)exponential, which is really poor, even if you have a fast CPU.&lt;p&gt;One may argue that these cases aren&amp;#x27;t common, but folks always test the boundaries with layout modes in CSS - so things need to be fast by default.&lt;p&gt;Note: In grid items size themselves differently depending on what tracks you place them in, which is why you need to place in every possible position.&lt;p&gt;Masonry potentially needs a different algorithm for sizing tracks to mitigate these problems, (the blog post doesn&amp;#x27;t go into these issues in sufficient detail). There may have been a version of grid sizing which didn&amp;#x27;t have item positional dependence but that ship has sailed.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;randomascii.wordpress.com&amp;#x2F;2019&amp;#x2F;12&amp;#x2F;08&amp;#x2F;on2-again-now-in-wmi&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;randomascii.wordpress.com&amp;#x2F;2019&amp;#x2F;12&amp;#x2F;08&amp;#x2F;on2-again-now-i...&lt;/a&gt;</text></comment>
<story><title>Help us invent CSS Grid Level 3, a.k.a. &quot;Masonry&quot; layout</title><url>https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/</url></story><parent_chain><item><author>achairapart</author><text>So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when Firefox first proposed it.&lt;p&gt;The news here is that people at WebKit decided to push the debate to the public, inviting designers and developers to take some action (“post to social media, write blog posts”), in order to get past this.&lt;p&gt;While it may look just like a formality, I think this will make an important precedent. The real underling debate here is either to treat every layout option as a part of the CSS Grid, or keeping adding new CSS Display proprieties as necessary.&lt;p&gt;The first option will make even more complex the (already convulsed, IMHO) CSS Grid specs, the latter will bloat the CSS specs with a load of new proprieties (and related sub-proprieties).&lt;p&gt;Either way, it&amp;#x27;s not as easy as it looks.</text></item></parent_chain><comment><author>mvonballmo</author><text>A &amp;quot;row-less&amp;quot; grid fits very well in the current CSS Grid specification, in that it can reuse the very powerful column-definition property as well as sub-grids. Their examples very convincingly show how orthogonal these features are.&lt;p&gt;Mostly, you just write grid-row-template: masonry and everything else just works with it. This is nice. It doesn&amp;#x27;t become harder to use the grid layout than it already is IMHO.&lt;p&gt;The drawback is mostly for browser-engine authors, for whom the bar for &amp;quot;fully supports CSS Grid&amp;quot; will be set even higher. They also mention that it might avoid &amp;quot;performance traps&amp;quot; where an implementation that needs to support all features of grid might be slower at some parts of grid layout than it would be if the specification were simpler.&lt;p&gt;If there were a separate display mode, then you&amp;#x27;d have to repeat the grid-column specification for the masonry layout, which seems a shame.</text></comment>