Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
1–10 of 359 posts
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#2A really nice feature here is that if you view the demos in a browser that doesn't support this (i.e. all current stable browser releases without special flags enabled) because they're building directly on grid layouts, they still appear in a pretty reasonable fixed-row format: https://webkit.org/demos/grid3/.
In each case it'd look much nicer with a proper masonry layout but it's still very usable otherwise (and of course you could feature detect to provide a better fallback if you're not happy with that anyway).
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#3If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#4I am wondering whether it makes sense to keep adding more "layout" options to CSS, given that we have the legacy floats and then the modern flexbox and grid layout. If there are still cases that are not covered, perhaps a better solution to to have one final constraints-based system that covers all layout cases, even if it comes at the cost of complexity. The CSS frameworks and utility libraries will then be built on top of it to provide the next generation of "masonry" grid, etc.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#5If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?
I’d rather have browser vendors responsible for a correct implementation. This seems like a rather nuanced feature.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#6For more background, and some detailed discussion of the opposite argument ("display: masonry" over "display:grid"+"grid-template-rows: masonry") see https://github.com/w3c/csswg-drafts/issues/9041
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#7If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?
It’s less smooth, uses more power, requires more bandwidth, etc.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#8If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?
You're asking "why render it correctly when we can render it wrong and then fix it afterwards".
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#9Oh yes please. Masonry is definitely the missing piece right now. And I run into cases where designers give it to me pretty regularly-- I don't want to crush their dreams but without a JS-free masonry solution, the dreams are getting crushed.
OK, having read a lot more, here's my thoughts.
I love the possibilities that can be raised here when masonry is built into grid, but you can target specific rows and columns for specific elements in grid. This is a useful thing for some layouts, but when the rows are truly non-existent (unlike the related auto fill/fit stuff we've had until this point) I feel like the abstraction begins breaking down. As much as I love that we have Apple pushing to get this done, I do think it is probably better to go with a net new masonry display type :-/
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#10If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?
Because why introduce a custom abstraction to implement something with an imperative scripting language when you can achieve the same result with a declarative language built specifically to address this use case?
You'd rather maintain all the maths and JS dependencies for this than have browsers just render what you want?