Part of the tension with building masonry on top of grid is that they work in fundamentally different ways.
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.
The first Firefox implementation (and the spec at that stage) basically said you don'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.
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't really have this in other layout algorithms.
With nesting introduced the performance goes (sub-)exponential, which is really poor, even if you have a fast CPU.
One may argue that these cases aren't common, but folks always test the boundaries with layout modes in CSS - so things need to be fast by default.
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.
Masonry potentially needs a different algorithm for sizing tracks to mitigate these problems, (the blog post doesn't go into these issues in sufficient detail). There may have been a version of grid sizing which didn't have item positional dependence but that ship has sailed.
Quadratic performance is a bit of an exaggeration. It's not O(N_items^2). It's N_tracks x N_items, and basically nobody has N_tracks ≈ N_items. Practically speaking, the upper limit is closer to (N_items^1.5) because N_tracks is unlikely to go over sqrt(N_items) in cases where N is large. And almost all of those layouts will have repetitive track sizing patterns, so they can be optimized to a much smaller N_tracks that approaches O(N_items).
Why does this require checking every item in every column? It looks like the layout algorithm greedily picks the column with the least total height so far, every time it adds an item.
The examples in the article seem to have CSS that directly sizes the columns, albeit with some flexibility such as being able to change the number of columns to better fit the width. It seems like the item widths depend on the column widths, rather than the other way around (which seems like it'd be circular). What's an example where the column widths depend on the items?
You first need to decide how big each of the three columns are going to be, then you want to place the items in each of the columns.
Depending on the non-fixed column type (there are different rules for each type) you want to ensure their constraints are satified (typeically they are big enough to encompass the items).
Thanks, that helps; I'd thought about variable numbers of columns based on the width of what they're contained in, but hadn't thought about the possibility of wanting to choose the number of columns to fit their content better. Mostly because I was imagining content like images that can be scaled or text that can be wrapped, rather than fixed-size content or content with a minimum necessary size.
Grid has a rich functionality for autoplacement of items and one of the arguments for masonry being part of grid is that you can easily mix the two positioning approaches
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.
The first Firefox implementation (and the spec at that stage) basically said you don'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.
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't really have this in other layout algorithms.
With nesting introduced the performance goes (sub-)exponential, which is really poor, even if you have a fast CPU.
One may argue that these cases aren't common, but folks always test the boundaries with layout modes in CSS - so things need to be fast by default.
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.
Masonry potentially needs a different algorithm for sizing tracks to mitigate these problems, (the blog post doesn't go into these issues in sufficient detail). There may have been a version of grid sizing which didn't have item positional dependence but that ship has sailed.
[1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...