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

261–270 of 359 posts

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

#261

Post by cnotv »

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…

It IS grid, lvl 3. You can achieve it with:

  display: grid;

  grid-template-rows: masonry;
This is however limited to webkit. I implemented it and ditched in October 2023 already for my private news feed in gallery mode.

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

#262

Post by The_Colonel »

recursive wrote: post #230
The_Colonel wrote: post #211

Earlier quoted context omitted.

JS DOM API is still abysmal and jQuery API is still great. No worshipping needed.

Really? Genuine question, which part? If there are too many to name, how about just one? It seems pretty good to me.

My favorite is this comparison for checking whether an element is hidden:

    $(el).is(':hidden')
vs.

    !(el.offsetWidth || el.offsetHeight || el.getClientRects().length)
DOM API has other problems like lack of chaining which forces you into a very imperative style of programming, e.g.:

    $(".alert").hide();
vs.

    for (const el of document.querySelectorAll(".alert")) {
         el.style.display = 'none';
    }

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

#263

Post by CodeWriter23 »

The_Colonel wrote: post #255
codingclaws wrote: post #238

Earlier quoted context omitted.

It is actually responsive, I think because I used percentages in the CSS.

So it makes pictures larger / smaller based on the screen width? Usually what is expected is that with narrower screen, you get fewer columns, pictures are still same-ish size. You also need to keep the order of the items (e.g. on a wider screen 1, 2, 3, 4 are all on one row, with a smaller screen 1 and 2 are on a row, then 3 and 4 on another row).

So no different than current design paradigms (which I loathe btw) which give you the exact same content regardless of viewport size.

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

#264

Post by bfgeek »

achairapart wrote: post #116

So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when Firefox first proposed it. The news here is that people at WebKit decided to push the debate to the public, inviting designers and developers to take some action (“post to social media, write blog posts”), in order to get past this. While it may look just like…

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.

[1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...

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

#265

Post by roblh »

I found a really cool way to do this with svelte and css grid a few months ago, based on a blog post I can't seem to find now. A full masonry layout too, not just columns, but each element can have dynamic height and width. The thing that made it click for me was that you don't have to make the grid rows and grid columns 1:1 with the full width/height of each element. Making 10px or 20px rows and columns and then using a svelte component for each image that chose a number of columns and rows based on the image aspect ratio. I'll see if I can make the repo public today.

Edit: reading further, I think my approach was basically the same as theirs near the end of the post!

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

#266

Post by The_Colonel »

CodeWriter23 wrote: post #263
The_Colonel wrote: post #255

Earlier quoted context omitted.

So it makes pictures larger / smaller based on the screen width? Usually what is expected is that with narrower screen, you get fewer columns, pictures are still same-ish size. You also need to keep the order of the items (e.g. on a wider screen 1, 2, 3, 4 are all on one row, with a smaller screen 1 and 2 are on a row, then 3 and 4 on another row).

So no different than current design paradigms (which I loathe btw) which give you the exact same content regardless of viewport size.

Sure, but different from what the masonry design is meant to facilitate (check the linked demos). It's very useful esp. for a photo gallery kind of sites.

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

#267

Post by recursive »

The_Colonel wrote: post #262
recursive wrote: post #230

Earlier quoted context omitted.

Really? Genuine question, which part? If there are too many to name, how about just one? It seems pretty good to me.

My favorite is this comparison for checking whether an element is hidden: $(el).is(':hidden') vs. !(el.offsetWidth || el.offsetHeight || el.getClientRects().length) DOM API has other problems like lack of chaining which forces you into a very imperative style of programming, e.g.: $(".alert").hide(); vs. for (const el of document.querySelectorAll(".alert")) { el.style.display = 'none'; }

I've never had a case where I didn't know the reason or mechanism by which an element would be hidden. In my code, I use the `hidden` property. In that case it simplifies from

    $(el).is(':hidden')
to

    el.hidden
It's not quite as succint as your jquery, but you also could have written this.

    document.querySelectorAll(".alert").forEach(el => el.hidden = false);
Is it less imperative? I mean I guess it doesn't have an explicit loop, but I don't really see why that's good or bad.

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

#268

Post by matsemann »

achairapart wrote: post #116

So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when Firefox first proposed it. The news here is that people at WebKit decided to push the debate to the public, inviting designers and developers to take some action (“post to social media, write blog posts”), in order to get past this. While it may look just like…

I think one additional point to consider when adding it as a new display mode vs re-using grid, is that currently these demo's fallback quite nicely now when it's re-using grid. Instead of showing it as masonry (since my browser doesn't support it), it at least behaves as a grid. If it's a new display: X property, it will fallback to div behavior with the content all over the place in unsupported browsers.

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

#269

Post by fzeindl »

I never understood why CSS would not just adopt Apple's Autolayout and be done with it: I want to specify that this space should be equal to that space, these borders to grow, and those borders to shrink and this point always aligned to that point.

It is simple, intuitive, it works for all cases. Instead we are inventing, what, the fifth generation of CSS-layouting now? Does nobody think this is odd?

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

#270

Post by laszlokorte »

matsemann wrote: post #268
achairapart wrote: post #116

So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when Firefox first proposed it. The news here is that people at WebKit decided to push the debate to the public, inviting designers and developers to take some action (“post to social media, write blog posts”), in order to get past this. While it may look just like…

I think one additional point to consider when adding it as a new display mode vs re-using grid, is that currently these demo's fallback quite nicely now when it's re-using grid. Instead of showing it as masonry (since my browser doesn't support it), it at least behaves as a grid. If it's a new display: X property, it will fallback to div behavior with the content all over the place in unsupported browsers.

you could simply do: "display: grid; display: masonry;" and all not-supporting browsers would skip the second declaration.
Post reply on HN