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

131–140 of 359 posts

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

#131

Post by echoangle »

crote wrote: post #112
thousand_nights wrote: post #74

Earlier quoted context omitted.

> incredibly easy to do with existing css care to demonstrate? given a dynamic collection of images where you don't know the aspect ratios beforehand

Does it actually solve that problem, though? In the photo demo all content is either 1-column or 2-column wide - and that already results in some very noticeable gaps. I don't get the impression that it can properly handle arbitrary aspect ratios. You're pretty much forced to stick to a single column width and fit all images to match, so not exactly an improvement over what we already have right now.

It does handle arbitrary aspect ratios by scaling the image to fit the width of the column. What else should it do? It also allows you to define different widths for each column. Isn’t that exactly what you want for a masonry layout?

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

#132

Post by nkozyra »

thousand_nights wrote: post #74
nkozyra wrote: post #49

Earlier quoted context omitted.

For awhile it was just described as "Pinterest style." It has some use cases but for the most part it's literally a wall of unstructed information. Difficult to parse and build any mental hierarchy. It's also ... incredibly easy to do with existing css.

> incredibly easy to do with existing css care to demonstrate? given a dynamic collection of images where you don't know the aspect ratios beforehand

All of the images have only a constraint on the width, the aspect ratio is irrelevant. You can still do it with a grid, you just let the browser render the images within as it would normally.

Where it gets more complicated is getting them all to align horizontally at the bottom, which even this proposal doesn't do. Pinterest, of course, solved this by not having a "bottom."

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

#133

Post by sausajez »

lloydatkinson wrote: post #127
wildpeaks wrote: post #81

Earlier quoted context omitted.

It makes sense they'd pick this name, it refers to the jQuery plugin that was popular for doing this kind of layout back in the 2010s, so it's a convenient shorthand.

[flagged]

Accidentally? How can something be intentionally/ unintentionally popular?

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

#134

Post by sn0wleppard »

tomp wrote: post #121

This is readily achievable today with `columns`: https://primozic.org/aesthetics-art

That example doesn't achieve the second objective of the proposal, "It distributes content across the page (instead of flowing down each column, one by one)."

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

#135

Post by 6510 »

My proposal would be to put the image dimensions in the name of the image file. example-400x200.jpg

Without that I cant think of an "easy" to implement formula to keep each column the same length.

If given a group of numbers, how would one divide them into 8 groups the same size?

Extra fun: You may increase each number by n in order to make each group exactly the same size. n must be as small as possible.

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

#136

Post by nkozyra »

echoangle wrote: post #131
crote wrote: post #112

Earlier quoted context omitted.

Does it actually solve that problem, though? In the photo demo all content is either 1-column or 2-column wide - and that already results in some very noticeable gaps. I don't get the impression that it can properly handle arbitrary aspect ratios. You're pretty much forced to stick to a single column width and fit all images to match, so not exactly an improvement over what we already have right now.

It does handle arbitrary aspect ratios by scaling the image to fit the width of the column. What else should it do? It also allows you to define different widths for each column. Isn’t that exactly what you want for a masonry layout?

If, for example, it rendered the child elements such that they automatically gained/lost overflow in relation to other columns, it might have some practical application that straight CSS cannot do. This would allow children to be sized vertically (effectively cropped) to produce an even square.

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

#137

Post by kreetx »

lloydatkinson wrote: post #127
wildpeaks wrote: post #81

Earlier quoted context omitted.

It makes sense they'd pick this name, it refers to the jQuery plugin that was popular for doing this kind of layout back in the 2010s, so it's a convenient shorthand.

[flagged]

It's often referred to as the masonry layout, so why not?

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

#138

Post by mmis1000 »

iainmerrick wrote: post #32
mg wrote: post #3

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

The main problem is that JS runs in a single thread and blocks the browser. Browsers jump through a ton of hoops to do scrolling and rendering on background threads while still allowing JS hooks and callbacks as required by web standards. But, I think it's really the ONLY problem, and if you solve that problem, doing this stuff in JS would be the right answer. You'd be much more likely to get consistent behavior ever…

You can actually make a working masonry layout with css alone(even make it work with browser resize), if you do know the aspect ratio of each item. The hard part is handling the column count change and item prepend/insert because that would always require js to do.(since tha would change the position and column of every item)

There is no logic of js required to do handle whatever screen resize.

https://codepen.io/mmis1000/pen/gOyZJqE

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

#139

Post by ptx »

rezonant wrote: post #24
chrismorgan wrote: post #15

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

So you're saying the a11y tree and tab ordering is bypassing the actual ordering of content and instead traversing the columns one by one? I'd call that a bug. In a masonry layout the expectation of a sighted user is that there is no continuity from column to column, but instead through the visual line. And the "unexpected" (disagree) ordering you show does that. I think the issue would be that tab ordering is ignori…

Maybe it's just me, but as a sighted user I have no idea how to read this kind of layout. My expectation would be that any sane designer wouldn't use this kind of layout in the first place.

What's the "visual line" in the first example? It goes 1, 2, 3, 4; then down to 5; then a sudden break in the line as it jumps over 3 to the left to reach 6?

Are we supposed to mentally sort the boxes by the top edge coordinates before reading? That would almost make sense of the second example, except that it doesn't explain why 9 comes before 10. Maybe sort by the coordinates of the bottom edge instead? But then 5 should be first. How do I read this thing?

Edit: Actually box 9 seems to start 1 pixel above box 10, so sorting by top edge does work! So a sighted reader simply has to zoom in to the pixel level and carefully measure the coordinates of all the boxes to find the reading order.

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

#140

Post by PhilipRoman »

zarzavat wrote: post #12
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.

With great power comes poor performance. I can immediately tell when a page uses JS for layouting (or replacing other browser functions like scrolling) as there is a noticable latency increase and the page lags about 200-300 ms behind when resizing the window.
Post reply on HN