Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

webkit.org

Post reply on HN
Print view View original

11–20 of 359 posts

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#11

Post by seumars »

m3h wrote: post #4

I 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…

The whole point of this initiative is to stop using out of date float-hacks, or soon-to-be out of date hacks to CSS grid or flexbox. Firefox's masonry layout is in fact implemented in such a way that basically covers all layout cases by simply adding a new attribute that collapses grid rows.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#12

Post by zarzavat »

m3h wrote: post #4

I 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…

JavaScript is the final layout system. No declarative language can ever handle every use case. Fortunately I rarely need to resort to JS since grid came out.

I’m not sure a constraint based system would do much good as it would sit awkwardly in the middle of grid and JS.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#13

Post by jampekka »

mg wrote: post #3

If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?

It'll probably end up slow and buggy. And likely explode when used with other layouting mechanisms. And it won't benefit from the quite awesome CSS debugging tools we have nowadays.

But yes, more powerful "client side" layouting functionality would be very welcome so we wouldn't have to wait the commitees for a decade to center an element etc. And there is the "Houndini" project to get this going, but the browser support is still extremely poor: https://houdini.glitch.me/

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#14

Post by bazoom42 »

m3h wrote: post #4

I 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…

You can always generate the layout in javascript if you have some requirements which aren’t directly supported by CSS layout.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#15

Post by chrismorgan »

I strongly dislike the megamenu demo https://webkit.org/demos/grid3/megamenu/>, and feel masonry is completely inappropriate there. It makes a complete mess of flow direction, badly breaking expectations.

The reading order you’d expect: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2.....

What the demo actually gives you: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1..... This affects correct reading order and tab indexes. Basically, sighted users will always read things in the “wrong” order. This just drives home that there is no structure, it’s just an unstructured bag of links. Except… actually if you go through them in numbered order, it looks like there was some fairly logical ordering. It’s just been utterly demolished by inappropriate masonisation.

(I’ve turned on “number items” in those screenshots. Normally, it’d look more like normal columns with no backgrounds.)

The way it should be implemented is with columns, but adding `break-inside: avoid` on each section, which their demo has missed.

The newspaper demo is also a little dubious for similar reasons, but it’s a much smaller deal.

Now images and such media which are in more independent blocks and where reading order isn’t such an ingrained thing, masonry layout does work better there. There are still patches where things can be a bit iffy, mostly around tab indexing, but it’s not obviously wrong any more.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#16

Post by pavlov »

isodev wrote: post #10
mg wrote: post #3

If 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?

It’s been nearly 30 years now that we’ve heard this refrain about CSS. Somehow the dream of “just tell the browser to render what I want” still remains elusive.

But maybe it’s just a few dozen more properties and mini-DSLs away this time! Pay no attention to those sirens and false prophets who still believe in anti-CSS “tell the computer how to do exactly what you want” programming…

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#17

Post by mattbessey »

> This layout creates uniformly-sized columns, without any rows

I find it amusing that they've decided to refer to this as masonry layout. If you actually built a wall like this (as opposed to uniformly-sized rows, without any columns) it would be a structural engineering disaster.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#18

Post by m3h »

seumars wrote: post #11
m3h wrote: post #4

I 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…

The whole point of this initiative is to stop using out of date float-hacks, or soon-to-be out of date hacks to CSS grid or flexbox. Firefox's masonry layout is in fact implemented in such a way that basically covers all layout cases by simply adding a new attribute that collapses grid rows.

>Firefox's masonry layout is in fact implemented in such a way that basically covers all layout cases

That's good to know.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#19

Post by jampekka »

xrisk wrote: post #5
mg wrote: post #3

If 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.

With browser vendors you have to get them to do the same implementation. With JS/WASM it'll work across browsers given the more fundamental APIs work the same.

Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout

#20

Post by isodev »

pavlov wrote: post #16
isodev wrote: post #10

Earlier quoted context omitted.

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?

It’s been nearly 30 years now that we’ve heard this refrain about CSS. Somehow the dream of “just tell the browser to render what I want” still remains elusive. But maybe it’s just a few dozen more properties and mini-DSLs away this time! Pay no attention to those sirens and false prophets who still believe in anti-CSS “tell the computer how to do exactly what you want” programming…

I'm no prophet and CSS, just like any other language has its quirks. And yeah, generally it is my job to try and tell computers what to do so I like powerful tools that let me do what i want :)
Post reply on HN