I've run the masonry layout (for my personal bookmark website) ever since I've found it in the browser settings.

grid-template-rows: masonry;

is going to be outdated then?

▲ miiiiiike 2 days ago | parent | next [-]

Yeah, there was a years long debate that effectively ended with: “We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.”

https://m.youtube.com/watch?v=yikbSQ6tvlE

▲

JimDabell 2 days ago | parent | next [-]

> We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.

I think that’s an exceptionally uncharitable description of what happened. This is a decision the WebKit team has been repeatedly publicly asking people to participate in for over 18 months.

> Help us invent CSS Grid Level 3, aka “Masonry” layout

> P.S. About the name

> It’s likely masonry is not the best name for this new value. […] The CSSWG is debating this name in [this issue]. If you have ideas or preferences for a name, please join that discussion.

— https://webkit.org/blog/15269/help-us-invent-masonry-layouts...

> Help us choose the final syntax for Masonry in CSS

> We also believe that the value masonry should be renamed.

> As described in our previous article, “masonry” is not an ideal name, since it represents a metaphor, and not a direct description of its purpose. It’s also not a universally used name for this kind of layout. Many developers call it “waterfall layout” instead, which is also a metaphor.

> Many of you have made suggestions for a better name. Two have stood out, collapse and pack as in — grid-template-rows: collapse or grid-template-rows: pack. Which do you like better? Or do you have another suggestion? Comment on [this issue] specifically about a new value name (for the Just Use grid option).

— https://webkit.org/blog/16026/css-masonry-syntax/#footnote-1

> [css-grid-3] Renaming masonry keyword

— https://github.com/w3c/csswg-drafts/issues/9733

▲

miiiiiike 2 days ago | parent [-]

The debates went on for years and following it closely became a poor use of time. Even the subgrid conversation seemed completely stalled. I think a lot of people tuned out long before any vote was discussed. I did.

▲

dagmx 2 days ago | parent [-]

But if you were the one who tuned out, then isn’t it uncharitable to describe it as their failing to make you aware of the vote? Isn’t it on you to stay in the loop?

Surely they can’t start just pinging everyone who might have cared at some point during the time to get involved.

▲

miiiiiike 2 days ago | parent [-]

I get what you're saying but making interminable arguments and keeping the "debate" going is a tactic. There's that CIA sabotage manual with the section about meetings and conferences, it can feel like that. The duration of these debates aren't usually measured in hours, days, or weeks, but years. And the people who dragging them on and staying in the fights are employed full-time to do exactly that.

It got to the point where I believed that subgrid was dead. FF implemented it but absolutely no one else did, for years.

Is it our fault for tuning out of the debate? Yep. But tactics were employed to achieve that exact outcome. I'm fine admitting that I tuned out. But it was a battle of attrition waged by people who were fine holding up progress indefinitely.

Is that how you want decisions to be made?

Ultimately I'm not too concerned what you call the masonry feature. However the debate over what to call it was an extreme case of bikeshedding. I would have rather given up the fight over semantics to resolve the non-issues and ship the feature years ago. As it stands we're still years away from actually being able to use the feature in production.

I've stopped waiting for companies, committees, or projects to change course. I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist. Why bother? I have an incentive to spend my time building features that users will use.

▲

dagmx a day ago | parent [-]

This feels very much tinfoil.

There’s no incentive to the companies or the employees to draw out the discussion, especially over something so trivial. It’s much more preferable to try and speed through things to get things done in a time frame that can be adopted.

And regardless, if you don’t feel it’s worth your time, then why cast aspersions that it was something clandestine and intentionally hidden? You could have shown up and kept up with it, just like everyone else involved presumably did.

	▲	miiiiiike a day ago \| parent [-]
		Eh, you’re trying to put words in my mouth. I didn’t ascribe a motive to anyone. Their reasons are their own and it only makes sense that the people who stay in these fights do it because it’s part of their jobs. There are people who, for whatever reason, keep debates going over small points of disagreement and prevent issues from being settled. Sometimes for years. Right? The older I get, the more likely I am to recognize and route around or ignore interminable debates. Especially if it’s not for a company, project, or initiative under my direct control. Remember, the question at the top of this thread was essentially “What happened to ‘masonry’?” Well, there were quibbles over the descriptors. I don’t care about quibbles. “masonry”, “grid-lanes”, “grid-masonry”, pick one, they’re equivalent. I don’t like it when quibbles block progress. Sometimes people and companies do want to block things. You’d have to ask them why. Like I said earlier: > I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist. Pick your battles… Actually, no, it’s usually better to ignore the fights and just get what you need to get done so you can move on.

▲

culi 2 days ago | parent | prev | next [-]

Wasn't Firefox the only browser that actually implemented `grid-template-rows: masonry` anyways?

It sucks whenever browsers backtrack on a W3C standard that reached "Working Draft" status but it doesn't seem like it's gonna impact many people

Besides, it's not being "deprecated". It will continue to work as it does. We just have a better alternative that the big 3 all agreed on.

▲

afavour 2 days ago | parent | prev [-]

Masonry was never “in”, no? Mozilla proposed it and were the only ones to implement it, behind a feature flag. Then WebKit proposed an alternative that was discussed at length:

https://github.com/w3c/csswg-drafts/issues/10233

	▲	miiiiiike 2 days ago \| parent [-]
		People have been dragging their feet on subgrid, masonry, etc for almost a decade. I followed it pretty closely for years but stopped when it started turning into a Christopher Guest mockumentary. Masonry or grid-lanes, who cares? I’m just glad masonry (the feature, Baseline 20XX) and subgrid (Baseline 2023) are finally here.

▲ rhdunn 17 hours ago | parent | prev | next [-]

The following should be compatible with both approaches:

    .masonry {
      display: grid;
      display: grid-lanes;
      grid-template-columns: repeat(auto-fill, minmax(180px, 1fr));
      grid-template-rows: masonry;
    }

Firefox and browsers supporting the old syntax will ignore the `display: grid-lanes` as it doesn't recognize it and fall back to the grid+masonry.

Browsers supporting the new syntax will override the `display: grid` with `display: grid-lanes` and ignore the `grid-template-rows: masonry` syntax.

▲ dylan604 2 days ago | parent | prev [-]

I still prefer the layout look from something like justifiedGallery.js where the heights of each row are the same. Actual masonry with stacking stones would never stack directly on top of each other like this. Calling it masonry just feels unnatural as anything stacked like that would easily be knocked over. "Lanes" is definitely more appropriately named than "masonry". The layout look of a justifiedGallery would be more masonry than the grid-template-rows:masonry setting. yeah yeah, raw css vs js library blah blah

▲

Doxin 2 minutes ago | parent | next [-]

One hack to almost get a justified gallery like that with no javascript is to lay them out with flexbox, setting their width to a percentage or vw value which your backend calculates based on image aspect ratio and desired image height, use flex-grow to stretch them to fill remaining space, and then using background-position: cover to make the images fit the slightly wrong aspect ratio containers.

This will of course slightly crop all your images to make it fit, but in practice as long as you keep your image aspect ratios reasonable and the images small enough on the page it's really quite subtle.

I had hoped that this feature would provide for masonry like that, but one has to make do.

▲

karlshea 2 days ago | parent | prev [-]

What you’re looking for is described in the article as “bricks” (vs “waterfall”) and is also supported.

	▲	notpushkin 2 days ago \| parent [-]
		Not quite – “bricks” would have a jagged edge on the right side, while “justified gallery” libraries produce even rows of the same length (but slightly different height), e.g. https://justifiedgallery.com/ or https://miromannino.github.io/Justified-Gallery/