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

271–280 of 359 posts

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

#271

Post by jjcm »

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 this will make an important precedent

It's worth noting this is not the first time things like this have gone to the community for feedback. They did the same for nested CSS selectors, which ended up working quite well feedback-wise: https://webkit.org/blog/13607/help-choose-from-options-for-c...

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

#272

Post by branmcconnell »

I’ll admit that I was skeptical at first about including masonry in the CSS Grid spec.

After reading through the article, I’m convinced it is the right path forward, allowing masonry layouts to utilize the same APIs and properties (columns/rows, gap, etc.) as CSS Grid.

This would lower the bar of entry by using familiar APIs and allow simpler switching between masonry and other column/row setups responsively.

```css .example { display: grid; grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); grid-template-rows: auto; @media (width > 500px) { grid-template-rows: masonry; } } ```

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

#274

Post by layer8 »

fzeindl wrote: post #269

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?

It’s difficult to unambiguously and usefully specify what should happen when not all constraint can be fulfilled. And you can likely also DOS browsers by exponentially exploding constraint calculations. CSS is bad as a layout system, but I also don’t like constrained-based layout systems unless they enforce that the constraints can always be fulfilled and be calculated in reasonable time. Which implies that you wouldn’t be able to change the layout willy-nilly client-side with JavaScript.

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

#276

Post by The_Colonel »

recursive wrote: post #267
The_Colonel wrote: post #262

Earlier quoted context omitted.

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

> I've never had a case where I didn't know the reason or mechanism by which an element would be hidden.

Unfortunately, I usually don't keep the whole codebase in my head (including libraries), so I often don't know the reason.

The more general point is that I don't want to have to know, because the mechanism of how it is hidden is not what I care about.

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

Yes, it's more than three times as long as the jQuery variant.

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

#277

Post by layer8 »

amadeuspagel wrote: post #248
account42 wrote: post #222

I absolutely hate this kind of layout, especially when combined with infinite scrolling. Makes it impossible to systematically go over all items.

It's not meant for things that you want to systematically go over, it's meant for things that you want to explore.

Some people want to go systematically over the items when exploring. I certainly tend to operate that way, and it’s infuriating when the UI is making it difficult for no good reason.

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

#278

Post by layer8 »

paulhilbert wrote: post #214
peebeebee wrote: post #165

Earlier quoted context omitted.

Why? When developing standards it's very good to have good gatekeepers. Not everything should be built inside the browser if you can achieve the same with existing technologies like JS. Otherwise your browser(standards) might become too complex.

That is an orthogonal discussion. I need masonry layouts a lot and tend to be on the "we don't need another display class" side in this debate. But that's unrelated to my "rant".

For what it’s worth, I found masonry layout always detrimental to my use of a site. I would prefer CSS not to encourage it by providing built-in support.

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

#279

Post by fzeindl »

layer8 wrote: post #274
fzeindl wrote: post #269

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?

It’s difficult to unambiguously and usefully specify what should happen when not all constraint can be fulfilled. And you can likely also DOS browsers by exponentially exploding constraint calculations. CSS is bad as a layout system, but I also don’t like constrained-based layout systems unless they enforce that the constraints can always be fulfilled and be calculated in reasonable time. Which implies that you would…

Checking that the layout isn‘t exponentially complex and DOSing the browser could be a simple task for the web developer. If you want your website to perform bad you can always find a way.

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

#280

Post by _akhe »

I do it on my portfolio site (https://www.bennyschmidt.com) in JavaScript by maintaining a `colCount` with each column just being `flex-direction: column`.

But after seeing this I should switch to using CSS. Didn't put too much thought into it, but when I realized it wasn't immediately simple in CSS grid just did it in JS.

Post reply on HN