Re: [csswg-drafts] Alternative masonry path forward (#9041)

@rjgotten If what you're saying is true, then yes, it would be a good argument for splitting the display modes. However, from everything I've read that is not the case. At least, not anymore. The Chrome blog specifically mentions that they found a solution to the performance problem.

> With masonry you don't have that computational complexity problem, because it only is in alignment on one axis.

You're hand-waving away a lot with that one sentence. From everything I can gather and think through, the only difference between masonry and traditional grids is whether rows are staggered or aligned across columns. The column widths themselves would need to be calculated in exactly the same way.

*If I'm wrong about this please correct me and explain how masonry changes how columns would be calculated intrinsically.*

---

#### To explain my own thought process:

The most naive approach for both traditional and masonry grids would be to start by picking the first N children that can fit in the first row. 

*And if you have dense grid:*
If you have some space left after placing `n` children and the `n+1`th element is too big to fit in that space, look for the next child that can fit in that space.

---

Place the rest of the children along the columns defined by the first row. Every child would go to the first column where it fits, but if it doesn't fit in any of the columns, it would go to the next available column.

*And in a dense grid:*
If any columns are skipped and a subsequent child can fit there, fill it.

----

#### Where I could be wrong

The biggest open question left in my thinking is if there would be some kind of automatic intrinsic behaviour for `grid-column: span`. Should children in the grid automatically span multiple columns in either of the two layouts?

Again, I think whatever the answer to that is, it is an answer that would apply equally to both layouts.

----

I will happily change my view completely if I'm presented any evidence for why automatically defining columns is possible for masonry but not grid. But for now, I see it as an artificial fragmentation of features that is being made available to one layout but not the other and this is *one* of the big reasons I think adding masonry to grid is the better solution. It forces us to design APIs to a higher standard for the future and not take the easy way out and create fragmentation.




-- 
GitHub Notification of comment by nmn
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2371870085 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 24 September 2024 17:15:22 UTC