return to table of content

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

pavlov
57 replies
7h9m

If the designers of Unix had seen the light of CSS, they wouldn’t have bothered with shells and file descriptors and C and Awk and all that composable flotsam.

They’d just created a single program, call it the “Central Software System”, and defined thousands of properties that let you control its state machine to produce the output you need.

Presto! The perfect computer. If for some reason someone needs a new kind of output, it can be added to the Central Software System via a friendly decade-long committee process.

And if the properties happen to conflict in how they define some output, well, the one company in the world who has actually implemented all of this “open standard” can decide what happens in that case.

afavour
31 replies
6h57m

It’s almost - almost! - as if the designers of Unix and of CSS work in completely different scenarios and with completely different constraints! Almost!

pavlov
30 replies
6h44m

And with this convenient domain excuse, CSS has managed to become a system that’s not a fit for any domain.

It’s incomprehensible to visual designers, incomprehensible to programmers, and incomprehensible to document authors.

On the upside, it provides a massive moat of sunk cost and implicit implementation dependency around Chromium, so at least there’s that.

camillomiller
8 replies
6h6m

It’s always funny to read people that just never understood CSS trying to convince everyone that CSS is impossible to understand!

crispyambulance
5 replies
5h50m

Yes, that's fair.

Sure, today we have grid and vanilla CSS is sane and useable by anyone who takes the time to learn the modern way of doing things.

But let's not forget what a long and tortured road CSS has taken to become what it is today. CSS was a total dumpster fire up until around when flexbox came out. It was SO HARD to make it do what you want for SO LONG.

The MOST BASIC NOTION of layout, putting things in a freaking grid, was missing from CSS for almost two decades. Yet, the grid concept has been around in application layout since the 1980's. I can't explain why it took CSS such a long time, and the explanations I've heard don't seem plausible to me.

It's understandable that folks who were around in the bad days of CSS are still kind of bitter. I was, and if I didn't take the time to see the new ways of using it, I would still be incredulous about CSS.

bazoom42
2 replies
3h56m

The MOST BASIC NOTION of layout, putting things in a freaking grid, was missing from CSS for almost two decades

This is not true. CSS have had ‘display:table’ for 25 years, which is a simple grid layout model equivalent to html tables. Content can be aligned in rows and columns.

‘Display:grid’ is much more powerful of course.

crispyambulance
1 replies
2h10m

Yeah, I remember those. It was intended as a way to make "tables" using divs.

That way, we could pretend to do page layout with CSS, while still feeling shitty about repurposing something meant for tables.

There's just no justifiable reason for putting whole-page lay-out on the back-burner for so long. So many other far less important things came out before grid, it feels almost like it was deliberately spiteful to delay it so long.

bazoom42
0 replies
52m

Why would you feel shitty about using ‘display:table’?

It puts things into a freaking grid as you asked for.

afavour
1 replies
5h5m

I can't explain why it took CSS such a long time

It is weird to look back on but the web platform essentially went through a dark ages for a while. You could say the same about why it took us so long to get to ES6 JS, too. The standards bodies were frozen in ice (and I don’t quite know why either), everyone was debating HTML5 vs XHTML and somehow the rest of the platform floundered for years.

marksbrown
0 replies
4h37m

Microsoft failed to capture the internet. IE6 can still cause sane minds to crack.

jampekka
0 replies
5h50m

I'd be surprised to hear anybody with intimate knowledge of CSS claiming to understand CSS.

bryanrasmussen
0 replies
5h55m

it's better on HN because you can get it combined with snide insinuations that they could have created a better layout system that would do all the things that CSS does, but also fix the various problems that CSS has.

However the glory days are evidently behind us, because these insinuations never end with "in a weekend" anymore.

miunau
6 replies
6h22m

Maybe you need better glasses. This proposal is coming from the Webkit team, ie. Apple. CSS is plenty comprehensible and using it gets better with every browser release as they are focused around yearly interoperability efforts.

pavlov
2 replies
5h59m

AFAICT, practically nobody picks WebKit over Blink/Chromium for new projects.

The reasons why Apple still maintains their own browser engine have to do with corporate prestige and expensive insurance policy. They can afford it because Apple is literally the world’s richest corporation.

Nobody else does anymore. Even Microsoft gave up on their own browser engine despite having 97% market share two decades ago. And Mozilla is bankrolled by Google as their own kind of insurance policy.

miunau
1 replies
5h7m

Safari has 24% of the browser market.

pavlov
0 replies
4h51m

Not on merit but simply by being the only allowed option on iOS. Nobody chooses Safari because it runs WebKit instead of Blink.

jampekka
2 replies
6h6m

I happen to quite like CSS (in comparison to any other layouting system out there), but I really wouldn't characterize it plenty comprehensible.

I'm quite certain there's no human on earth that could reliably predict the outcome of most non-trivial real-life CSS layouts given just the code. And even though the situation has improved a lot, it's still common to have to use clearfixque hacks that definitely weren't envisioned by the commitees.

echoangle
1 replies
5h48m

Isn’t that true for most software? Do you think you can simulate the outcome of a semi complicated Python Codebase just by looking at it? That’s just an intrinsic property of the problem you’re dealing with, adaptive page layout will always be complicated and not easily understandable just by looking at code.

jampekka
0 replies
5h2m

I think I'd have a lot better shot with a semi-complicated Python codebase to be correct. Even with GUI stuff if using something like e.g. Qt box layouts.

Yes, CSS is a lot more powerful than those kinds of systems. Perhaps comparable to constraint satisfaction layouts that tend to be quite surprising.

But even so, there are so many settings and their combined behavior in CSS that it's, for me at least, totally infeasible to try to code much CSS "up-front" without constantly checking the result of the changes. And I don't mind it that much, but I'm quite certain that a more "predictable" equally powerful layouting system is entirely possible.

It could be an interesting challenge to show people some layouts and ask them to produce them using CSS without being able to iterate the results.

afavour
3 replies
6h39m

I’m a web programmer and I find it comprehensible. Sure there are times I need to go to the docs but vast majority of the time I can work with it just fine. I’d agree that it probably is incomprehensible to many visual designers but unfortunately so is code in general. CSS is complex, especially these days, but I feel like those who don’t work with the web every day simply don’t get to experience it often enough to know that it does make sense within its domain.

But sure, if you want, CSS is a conspiracy theory to ensure the dominance of Google.

pavlov
1 replies
6h20m

It’s not a conspiracy. It’s a well-intentioned but poorly thought-out design for basic 1990s word processing layouts that accidentally blew up to describe entire application GUIs, and now it’s not in the interest of the stakeholders to try to do anything about it.

It’s the same kind of growth pattern as government bureaucracies. Those are largely not conspiracies either, despite the occasional optics.

afavour
0 replies
6h8m

What you’re describing is the organic growth of a platform. The web is undeniably more complex than it was twenty years ago but needs are more complex too. Yes, the complexity does benefit major players but that isn’t the reason the complexity exists.

It’s ironic you’re saying that CSS is some form of vendor lock in. I have to imagine that if Google proposed a new layout engine for the web tomorrow they’d be roasted to kingdom come for their attempt at taking over the web.

Joker_vD
0 replies
6h35m

Of course it is, there is even the word "masonry" in TFA's name!

snapcaster
1 replies
6h2m

Not fit for any domain? It's one of the most widely used "programming languages" in the world. It's clearly fit for many domains I don't know why people have to be so dramatic with their tech opinions

bodantogat
0 replies
5h38m

I don't get the drama either. The issue I have with CSS is less about the spec itself, and more about browser compatibility. I'd be dead with caniuse.com and MDN. Having said that, when I build a new page, I rarely need to spend more time laying out the html & css than it takes to type it out and test. Creating cross platform, responsive web pages is a solved problem now.

FartinMowler
1 replies
6h21m

What would you propose instead that is comprehensible to visual designers, programmers, and document authors?

cqqxo4zV46cp
0 replies
6h9m

The inane and utterly incomprehensible toolset that they happen to be more familiar with, obviously. Some people take their ball and go home after they can’t work out how to centre a div, after decades of having “HTML and CSS are for the ‘stupid’ developers” drilled into them, and thinking that they can intuit it.

yau8edq12i
0 replies
6h20m

And yet, somehow, I browse websites using CSS successfully every day. Reality disagrees with your narrative, which is nothing more than a pandering "CSS bad" with little substance. "Not fit for any domain", "incomprehensible", these insults are based on what, exactly?

whywhywhywhy
0 replies
4h22m

It's honestly not that difficult at all, saying that as a designer.

greasyphalanges
0 replies
6h7m

I will concede to an argument that CSS exemplifies "design by committee" pejorative and is blighted by backward compatibility woes, but rest assured, it does its job as best as it can. Web development has patchworked its way out of most problems it has created, making it somewhat burdensome to learn. I'd say that is its Achilles's heel.

gherkinnn
0 replies
6h0m

Nonsense. CSS works. It has its quirks, but what doesn't?

What I do see here, is one of many cases of "I don't understand it therefore it is dumb because it can't be my fault".

dada78641
0 replies
6h2m

While I agree that CSS is sometimes difficult and obtuse, and getting things working in it is more of an art than a science, it's actually shockingly easy to get basic layouts working in it these days even as a total beginner. CSS is very powerful and you can learn the basics very quickly.

It's also worth keeping in mind that CSS is sometimes more complicated than it seems like it should be due to accessibility concerns and flexibility. That's why you can take some HTML produced by some part of your system and use it in completely different contexts with totally different designs, entirely as is, just by adding a few different rules.

I've been doing HTML dev since the late 90s and things were infinitely more difficult back in the old days. CSS might have been simpler, but doing complex things required tons of bizarre hacks that also made your design more frail and less accessible. These days CSS has improved to the point where you can do just about anything, and even very complicated effects can fairly easily be deconstructed just by looking at the devtools and poking around until you get it.

CSS isn't perfect, but all things considered I'm not complaining.

bmacho
0 replies
5h59m

But your favorite 20% of CSS (just like in the old days + some of the new features) fits nicely for web design.

klabb3
3 replies
6h47m

CSS may be complex, but you get a huge bang for the buck in terms of UX, rendering performance, flexibility, accessibility, compared to most drawing and layout systems. You could argue against border-radius and flex as well, but Im glad we’re past clearfix and gifs for corners. Does masonry layout qualify for becoming standard? I don’t know.

blackbear_
2 replies
6h21m

compared to most drawing and layout systems

This is just an accident of history and not because CSS has anything that makes it intrinsically better than the alternatives.

klabb3
0 replies
2h52m

Accumulated garbage for backwards compatibility? Let him who is without sin cast the first stone.

I’m not saying css is intrinsically better (what does intrinsic even mean in this case?). It’s pragmatically better than anything else I’ve seen. It’s dead simple to learn and use, and (almost) fully declarative, and degrades gracefully. Just show me a better alternative and I’ll change my mind.

jampekka
0 replies
5h44m

Anything other than existing.

CSS is quite a mess, and I would welcome a backwards-incompatible new layouting system, but all the alternatives out there are a lot worse.

sebstefan
2 replies
7h6m

You can say that about almost any abstraction layer

gwervc
1 replies
6h57m

The WPF has easy to use grids and layouts, a sane default styling yet is very to completely overhaul. CSS is a failure by design.

sebstefan
0 replies
4h59m

Yes, but that's a completely different point

mejutoco
2 replies
6h32m

What is the composable unix approach for layout/graphical interfaces?

mrighele
1 replies
6h20m

Tcl/Tk ?

When you had enough of using text as the single data structure in a shell, you can start doing the same with a GUI toolkit.

alpaca128
2 replies
6h49m

Did the designers of Unix also have to ensure compatibility with billions of devices connected worldwide running different software stacks?

Also as mentioned in the linked article the masonry layout is already possible with JS, no decades-long committee process needed. It's just about standardizing something frequently used.

kevincox
0 replies
6h39m

It's fine, just run ./configure before compiling.

btbuildem
0 replies
6h4m

The point GP is making is that they didn't have to, because the architecture made it infinitely configurable while remaining coherent.

Billions of connected devices worldwide do indeed run on *nix with a mad variety stacked on top.

lumb63
1 replies
5h57m

I didn’t realize this was satire until the second paragraph. Well done.

As a firmware engineer who is trying to build a website in his spare time, I find CSS absurd. I’ve found SCSS and Sass make it much more bearable. The ability to represent a hierarchy concisely is awesome.

datascienced
1 replies
6h59m

Is this a sysvinit vs systemd rant?

HeckFeck
0 replies
6h41m

   $ /etc/init.d/initwar start
   Starting initwar (via systemd)
Sad sysadmin noises

wodenokoto
0 replies
6h26m

What dynamic layout system is it that ships in posix again?

smokel
0 replies
7h5m

They would probably also use regular expressions and incomprehensible $ and \ escape codes to retain some of the fun.

micromacrofoot
0 replies
3h39m

the committee process is probably down to about 5ish years now? I feel like people who complain about this weren't around when the process was "20 years from now when we can drop IE support" — velocity has improved significantly

jojobas
0 replies
6h1m

Was rather hard to tell if you're joking or not, seeing how every trivial program today wants to have Electron with it.

jampekka
0 replies
6h32m

Trusting us plebs with universal turing machines is unacceptable. There's a config/app/saas/appliance for everything you need to need.

doctor_eval
0 replies
6h37m

I want to say something about monolithic kernels but I’m too scared.

dartos
0 replies
6h57m

Nixos?

cjk2
0 replies
6h17m

Um, err, POSIX.

mattbessey
40 replies
7h16m

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.

wildpeaks
13 replies
6h25m

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.

lloydatkinson
12 replies
5h35m

Heavens help us if we are naming features after an accidentally popular library like jQuery.

lloydatkinson
4 replies
4h29m

I made the mistake of forgetting HN simultaneously hates the web and JavaScript but worships jQuery

The_Colonel
3 replies
2h44m

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

recursive
2 replies
2h6m

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

The_Colonel
1 replies
40m

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';
    }

recursive
0 replies
26m

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.

sausajez
2 replies
5h31m

Accidentally? How can something be intentionally/ unintentionally popular?

PurpleRamen
1 replies
4h13m

Marketing makes something intentionally popular.

Accidentally, seems harder. It kinda smells for people to intentionally make it not popular by actively working against fame, or something like that..

robertlagrant
0 replies
2h0m

Accidentally, seems harder. It kinda smells for people to intentionally make it not popular by actively working against fame, or something like that..

It's not harder; it's the only thing that works for tools. Tools cannot be good for long because of marketing. Marketing is the thin layer of paint over the Ferrari. Very nice paint, but if the car doesn't work or go very fast very quickly then that's that.

kreetx
1 replies
5h26m

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

chickenchase-r
0 replies
5h16m

because every new construction requires a solid cornerstone? every archway a keystone? dont forget to put your boots in the trunk and your trunk in the boot. Nucular aluminum? I dunno

throwup238
0 replies
2h15m

That ship sailed with JAVAscript in 1995.

robertlagrant
0 replies
2h3m

It wasn't accidentally popular. It was just very good.

georgesimon
8 replies
6h48m

I think, in structural engineering terms, it refers to old natural stone wall [0] construction methods. Some bridges around me are made like this, and they're over a thousand years old.

But I agree that it's not a good adjective because I had the exact same first thought. Both "natural" and "stonewall" would be better, and they're not great names either.

[0]https://duckduckgo.com/?q=natural%20stone%20walls&ko=-1&iax=...

treflop
2 replies
2h53m

Masonry just refers to working with bricks. It's old as time but we still make stuff out of bricks and you can still be a mason today.

https://en.wikipedia.org/wiki/Masonry

georgesimon
1 replies
2h23m

It seems your are saying it is only relates to bricks? But it's not, it's any stone, cut or formed.

treflop
0 replies
1h36m

I suppose I’m using brick by its informal definition as just a construction block.

https://en.m.wikipedia.org/wiki/Brick

But yes, historically brick meant just one type and style of material.

rezonant
1 replies
6h37m

There's no gravity here, so the comparison makes no sense. In walls masonry construction produces sheer lines horizontally, an axis gravity is not bearing upon. This feels like taking the metaphor just a tad too literally.

georgesimon
0 replies
2h17m

I didn't think so, of you look at old stone walls, there's an absence of continuous horizontal or vertical patterns. (However the discussion was a fork, about wall building, so it was quite literal)

mewpmewp2
1 replies
4h13m

I associate masonry with the old ages, since this is one of the technologies you research in Civ games and back then I think people did have stones in non-standardized shapes and were just trying to fit things together. I'm not native English speaker, so I first heard this term from the games.

georgesimon
0 replies
2h15m

Yes, it has that association in English.

HPsquared
0 replies
6h46m

Surely they would not build like this. You want to avoid vertical shear planes.

wongarsu
1 replies
6h38m

Maybe there should be a grid-template-masonry-direction? Just quickly surveying a couple of sites, "masonry" and "horizontal masonry" seem to be about equally common.

On the other hand horizontal masonry is constructed very differently: Flickr fits thumbnails into a row until it reaches some predefined total length, then scales everything down slightly so the total row width matches exactly (resulting in rows of different height). Deviantart does something similar, but shuffles the images for better fit so that the different row heights are barely perceptible.

chuckadams
0 replies
1h20m

Filling rows without any defined columns is more or less what flexbox already does.

mrighele
1 replies
6h8m

Nothing that a transform(90deg) cannot solve :-).

More seriously, what you describe is quite doable with flexbox (flex-direction: row, flex-wrap: wrap and flex-grow: 1).

Interestingly, even the Masonry layout was already doable using a simple multi-column layout, the "only" issue is that instead of having the items left-to-right, top-to-bottom (ordered by row) you have them top-to-bottom, left-to-right (ordered by column) which is not what you want most of the times

hennell
0 replies
5h16m

There's a CMS I use that has a photo search option. It loads in images in a column ordered masonry layout, which when you scroll down adds new images to the columns, so all the pictures move about and you've no idea where you are.

It's infuriating.

datascienced
1 replies
6h57m

Might be ok for a footpath?

FalconSensei
0 replies
43m

Masonry layout is pretty common for streets, sidewalks, driveways, etc, at least in Brazil

cfj
1 replies
7h5m

Probably influenced by the most popular JavaScript library for achieving this type of layout, Masonry[0]. The author notes at the end of the article:

But do expect the name of this value to change in the future. And perhaps prepare for a future where we call this “columnar grid” or “Grid Level 3” instead of “Masonry”.

[0] https://masonry.desandro.com/

joenot443
0 replies
1h39m

I expect this is the case, if I had to describe that layout in iOS-land I'd also call it "masonry".

It's a pretty common descriptor in the Wordpress world - grids/scrapbooks will often have masonry as one of their layout styles. Maybe 100 years from now when people are browsing in their neurodisplay they'll be able to think "masonry" and have their photos tile the way they like, never having heard of Javascript or CSS in their lives. Language is neat like that.

Terretta
1 replies
7h0m

amusing that they've decided to refer to this as masonry layout

They haven't decided this. Keep reading!

TL;DR:

Perhaps the best syntax could be grid-template-rows: none; to convey “please do not give me any rows”. Sadly, it’s too late to use this name, because none is the default value for grid-template-* and means “please give me only implicit rows, no explicit ones”.

Instead we could use the name off to convey “please turn off the grid in the row direction, and give me only columns”.

    grid-template-rows: off;
But do expect the name of this value to change in the future. And perhaps prepare for a future where we call this “columnar grid” or “Grid Level 3” instead of “Masonry”.

rezonant
0 replies
6h56m

This is creating a mode of grid where we say "it's not actually a grid" and is my biggest problem with this philosophically. It makes more sense to treat it as it's own display type, where the row/column targeting don't exist. It's not just that row targeting doesn't exist, it also makes no sense to target columns.

account42
0 replies
2h15m

Most infamous.

rezonant
0 replies
7h5m

But masons build floors like this all the time, and it is not an engineering disaster. That's the metaphor.

The reason you think it would be a disaster is the load of gravity against it, a concept they have not yet introduced into CSS, thankfully.

paulddraper
0 replies
4h17m

Thank you. I was confused as well.

A name for the inverse I suppose

londons_explore
0 replies
6h19m

From a structural engineering point of view, this is because of the extra 1G of force keeping the rows together, but nothing keeps the columns together.

Since bricks have some tensile strength, but mortar (the 'glue' between rows and columns) has ~none, that means that, if you must have lines of weakness, you would prefer they be horizontal than vertical.

exyi
0 replies
6h47m

I think this is just transposed masonry, the wall looks ok if gravity is on the left. "Transposed" is redundant though, since I assume it will work in both grid-template-columns and grid-template-rows

dkdbejwi383
0 replies
6h35m

Wonder if they'll add support for `masonry-arrangement: flemish-bond;`?

mg
26 replies
7h36m

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

isodev
10 replies
7h22m

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?

pavlov
5 replies
7h17m

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…

isodev
3 replies
7h13m

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 :)

pavlov
2 replies
7h6m

You’re missing the irony in the second paragraph. CSS proponents are ideologically opposed to simply telling the computer how to do what you want.

sham1
0 replies
4h17m

Well, as far as I at least understand it, the argument is that by using JS for this, you are indeed telling the computer what you want, you're just doing it by telling the computer it by telling it exactly how to do it. In contrast, in CSS, you're telling the computer what you want by… telling it what you want, and letting the browser engine worry about the how.

CSS isn't perfect, but it certainly works nicely for declaring layouts most of the time. It's of course alsp easy to get wrong, but doing all of the layout logic manually doesn't seem like a proper solution.

jampekka
0 replies
4h9m

I agree that there should be an "escape hatch" to implement stuff that evaded the great wisdom of the commitees. The Houdini project may become such: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Houdini

But I do also see the benefit of a declarative system for most cases. Adaptive layouts are hard to do with imperative code, and very easily lead to e.g. infinite loops, so it's nice to work with a declarative system that guarantees a stable layout. That said, CSS is far from an ideal such system with so much ad-hoc and legacy baggage.

blowski
0 replies
7h9m

Is it easier to build a layout with CSS compared to 20 years ago? Yes. Can we further improve CSS? Yes.

crote
3 replies
5h44m

The question is, where do you draw the line?

It's obviously not viable to implement literally every single design imaginable straight in CSS. If I want to do something silly like placing my content on the faces of a hypercube it wouldn't be realistic for me to expect that to be part of CSS. Having me write some JS is completely acceptable - that's what it is for, after all!

It's not a matter of "would this be better in CSS", the answer to that is painfully obvious. The relevant question here becomes "is this common enough that it warrants a CSS implementation". And honestly? In the case of Masonry I am not convinced it is.

mvonballmo
1 replies
4h27m

As they explain in the article, a row-less layout with columns is quite common in the non-web world. They acknowledge that some people are arguing that it's not needed because nobody's using it (on the web). Nobody's using it (on the web) because it's not possible in CSS.

The argument is that the popularity of the layout in contexts where it's possible is a strong argument for enabling it on the web as well. This is not a layout that they just thought of and are trying to invent.

crote
0 replies
2h1m

I'm not seeing any evidence for that, though.

Row-less layouts with columns are indeed quite common in the non-web world - see for example newspapers or other dense text. But that can already be done with current CSS features, and the row-first placement makes this proposal completely unsuitable for that. Masonry actively makes that worse, because it screws with the regular reading order.

They argue that nobody is doing it because it can't be done in CSS. I would argue that nobody is doing it because it's a bad idea. We've seen people work around it not being in CSS by using Javascript to make galleries for years now, if there were other use cases they'd surely have done the same?

With the exception of Pinterest-style galleries (and lets be honest, that's not exactly the pinnacle of UX either) I really don't see a widespread use for this feature. Their three other demos sure aren't convincing me.

isodev
0 replies
5h3m

I totally agree, and it does make sense to make adjustments that would make layouts more accessible. Mansonry-like layouts are common ("make it look like Pinterest") and so why not facilitate this entire class of use cases? The alternative is for everyone to either look for libraries or hax-together something that looks like Masonry but don't look too close and don't resize the view port too much.

Honestly, I'd say kudos to the WebKit folks for opening the discussion and being transparent about the process and the tradeoffs. It can certainly help refine (or inspire) future proposals.

rezonant
5 replies
7h2m

There is no reasonable fallback when JS is not present or hasn't yet executed, and that's not acceptable.

I can't stress enough how important this is for content experiences. Your content must display reasonably before all bells and whistles load, and when the bells and whistles load, your content had better not shift dramatically (ideally not at all).

sebzim4500
4 replies
6h52m

I would expect most browsers that aren't running JS do not properly handle state of the art CSS extensions.

rezonant
2 replies
6h46m

Such browsers can also get by based on the semantic ordering of content within the document, which will more closely match the visual reality when a masonry type layout is used. The alternative of defining several columns leads to at least one column being shoved all the way at the end of the document after the previous column, whereas in a masonry layout that wouldn't be the case.

This is where a proper solution to this problem shines: After all, when you are on mobile (at least 60% of your users), they will get a single column anyway. Any solution that doesn't solve for them is a nonstarter.

That being said, it is the slow loading of JS and the folks using truly modern browsers with JS turned off that are more common, and for those people this isn't a problem.

jampekka
1 replies
6h19m

JS masonry libraries, e.g. masonry.js, can and typically do use the HTML for the content and just lay it out similarly to what CSS does.

rezonant
0 replies
1h30m

But the screen size is an important part of how the library will lay out the bricks, and that isn't known until JS runs (this can kind of be done with client hints, but not on initial page load)

kevincox
0 replies
6h35m

Or is your average email client? Many of these support modern HTML with scripting and remote content disabled.

xrisk
1 replies
7h33m

I’d rather have browser vendors responsible for a correct implementation. This seems like a rather nuanced feature.

jampekka
0 replies
7h13m

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.

nolok
1 replies
7h23m

You're asking "why render it correctly when we can render it wrong and then fix it afterwards".

datascienced
0 replies
6h55m

An argument I would take more seriously if infinite scrolling was not a requirement too.

iainmerrick
1 replies
7h4m

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 everywhere, without browser-specific quirks.

And part of the solution exists already! JS doesn't have to block the main thread any more, because you have things like Web Workers and WebAssembly.

Rather than adding another specific layout type, we should add a general-purpose way of hooking into the layout engine from a background task.

Update to add: just saw from another comment in this thread that there's already an effort underway to do this, called Houdini: https://news.ycombinator.com/item?id=40130487 Cool!

mmis1000
0 replies
5h23m

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

tambourine_man
0 replies
7h26m

It’s less smooth, uses more power, requires more bandwidth, etc.

jampekka
0 replies
7h19m

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/

greasyphalanges
0 replies
5h16m

By doing it in CSS you eliminate the need to re-render your DOM and make your JavaScript do more useful tasks, and make your website more resilient to scripts crashing, freezing, or being disabled by the user. Also, one would think that a pipeline of JavaScript + rendering engine falls short to a more direct solution, as browsers cheat by not using JavaScript ;)

paulhilbert
19 replies
4h52m

"Others are questioning whether or not this kind of layout is needed on the web at all — they aren’t sure that well-known websites will use it."

Would it instead be possible to exclude anyone with that attitude from a discussion about an open standard? I know this sounds toxic, but I would argue that approaching public design this way is ultimately more toxic wrt the outcome and those affected by it.

Or maybe I misunderstood that part since everyone seems to not be bothered by it at all here...

paulddraper
3 replies
4h19m

Surely questioning the real world usefulness is not "toxic"?

CSS is already very complicated. Adding more options needs proportionally strong justification.

Turing_Machine
2 replies
3h44m

No, but basing capabilities solely on what they imagine "well-known websites" might want is.

paulddraper
1 replies
3h13m

And how would you do it sans imagination?

paulhilbert
0 replies
2h43m

I mean the actual point of the article is to ask everyone, not just "well-known" examples.

So it seems there were some reasonably forces in the discussion that align with my stance without the unnecessarily antagonistic (and rhetoric) primer I should've probably left out.

Seems like a good approach to widen the discussion and improve the design.

cornstalks
2 replies
4h24m

Questioning whether something new is actually needed is absolutely worth doing, so long as it’s done respectfully.

This is a standard that affects billions of people and many implementations. It’s great to ask if something is really needed or if it’s just adding bloat.

We shouldn’t just grow the standard without first asking if the growth and added complexity carry their own weight. If someone proposing something can show that, then wonderful.

But yeah, just straight up trying to block these people from being able to ask these questions totally is toxic. As long as they’re asking and participating respectfully there’s no need to be a jerk toward them.

paulhilbert
1 replies
2h47m

Again: when did "well-known websites use this" become the motivating factor behind standard design?

The blink tag was used by well-known website and it's universally recognized as a bad decision.

cornstalks
0 replies
1h57m

It’s fine if you disagree with the premise of the question. But it’s also fine to ask the question, since presumably the asker wants to know the feature would get enough usage to justify its addition to the specification, and an easy way to show it gets usage is by showing some well-known sites would use it.

But what is not fine is trying to exclude people from the conversation and silence them just because you have a disagreement.

bezbac
2 replies
4h27m

I can totally understand the quoted comment. I mean, we are talking about CSS as a language here. Anything that is formalized is expected to be implemented and supported by browser engines and vendors. Browser engines are already extremely complex, so it's fair to think closely about formalizing new things when it's not apparent that there is a big enough need.

I'm not claiming this is the case with the Mansory layout; I just understand that adding unnecessary complexity for a small target user base is a valid concern.

paulhilbert
1 replies
2h52m

I totally get that. But for me there is a fundamental difference between "big enough need" and "well known websites need this".

How are potentially thousands of niche websites less of an argument than "instagram and co don't need it"?

The_Colonel
0 replies
2h35m

Well-known == highly visited == native implementation will have large accumulated impact on end users (their performance, energy consumption, improved usability ...).

PurpleRamen
2 replies
4h20m

Why? Any feature is a liability, so it's good to question whether a feature has to be implemented, and whether it should be in this way and position, or maybe somewhere else.

paulhilbert
1 replies
2h50m

Where is the connection to "well-known websites"?

PurpleRamen
0 replies
2h3m

I assume, with "well-known", they mean popular. Which means they (also) measure the worth of this feature by the number of users which might benefit from it. This is a very legit metric for this kind of situation.

rolha-capoeira
1 replies
4h48m

And honestly, that's a ridiculous claim. Two very popular websites I can think of right away are Pinterest and VSCO. (Perhaps VSCO on the web isn't as popular as the mobile app, but the company continues to use masonry as the design evolves.)

grub5000
0 replies
4h30m

Lots of sites that return a ton of images, like an of the image search sites (Google, Bing, DuckDuckGO, loads of porn sites etc.)

peebeebee
1 replies
4h26m

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.

paulhilbert
0 replies
2h38m

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

krsdcbl
0 replies
4h9m

I heavily agree!

This take is imho dangerously conflates personal taste and motivation with "should a heavily generalized and clearly purposed layout system be complicated with some magic keyuword options to serve your specific intents?", and misappropriates the assumption that people like and use this form layout as a reason to approve the latter.

gwbas1c
0 replies
4h30m

Would it instead be possible to exclude anyone with that attitude from a discussion about an open standard?

That attitude is rather critical and important to the discussion.

I don't think it's the browser, or the standards bodies, responsibility to have built-in support for every possible feature we can imagine. Instead, the standards need to be simple and extensible so that that libraries (Javascript or WASM) can do creative layouts. (IE, instead of waiting for Masonry layout in CSS, you should be able to grab a Masonry layout library and include it with your web site.)

Otherwise, we're building a system where the standards (CSS in this case) are so complicated that it's getting harder and harder to implement the standards; and are too inflexible to support what tomorrows' developers can imagine.

achairapart
15 replies
5h50m

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 a formality, I think this will make an important precedent. The real underling debate here is either to treat every layout option as a part of the CSS Grid, or keeping adding new CSS Display proprieties as necessary.

The first option will make even more complex the (already convulsed, IMHO) CSS Grid specs, the latter will bloat the CSS specs with a load of new proprieties (and related sub-proprieties).

Either way, it's not as easy as it looks.

reactordev
3 replies
1h50m

CSS Grid is a mistake. Baking in a design philosophy when we had really creative pages without it.

I like grids for pages with content and documentation and such. I don’t like grids for pages of media or other creative content. Cards, flex box, grids, these are all design framework choices and shouldn’t be in CSS spec. We were totally fine with position relative and media-query centric widths and heights. I get that it’s easier to standardize if grids are part of the standard but I miss the days of pages having some creativity in their design. Every site looks the same nowadays.

And before I get downvoted. I have a degree in graphic design. I love CSS and I love the web. Bring back the fun.

rhdunn
0 replies
1h45m

CSS grid makes it possible to implement wrapped content that is uniformally aligned with the last row keeping the same number of columns as the others, and have that scale correctly to different page widths. This is useful in things like book layouts. You can get close with flex, but the last row doesn't fully work.

krsdcbl
0 replies
41m

It was "fun" when tinkering with some really creative special concern, it was an insufferable pain when your job was finding ways to layout all the "fun" designers envisioned who weren't highly familiar with CSS.

Before position and float madness and all, we used to abuse tables -- because layouts for complex information do work best in grid systems. Now CSS finally has a module that serves this purpose, and brings a huge amount of flexibility to make formerly painful stuff easy.

I'm not even talking about "page layouts" as a whole, just simple particle patterns like "a big icon with a title + description to it's right" is so so much cleaner and easier to do in markup AND css with grid.

Embrace the tools, and if you dislike them - you may as well just not use them. But thinks like grid make simple, stupid, deadlined webdesign _work_ so so much less of a grind.

(speaking as a General Graphic Designer who's also been deep, deep in CSS since before 2.1)

fatbuoy1
0 replies
1h20m

Sure what was wrong with table layouts and spacer gifs anyway amirite?

I’m a designer who codes, and CSS Grid has completely transformed (and simplified) my approach to responsive web design, and enabled much more complex layouts as a result. Just because a layout was possible before doesn’t mean it was easy.

By all means do things the old way if you want, but to suggest that it would be better if it didn’t exist is insane.

mvonballmo
2 replies
4h44m

A "row-less" grid fits very well in the current CSS Grid specification, in that it can reuse the very powerful column-definition property as well as sub-grids. Their examples very convincingly show how orthogonal these features are.

Mostly, you just write grid-row-template: masonry and everything else just works with it. This is nice. It doesn't become harder to use the grid layout than it already is IMHO.

The drawback is mostly for browser-engine authors, for whom the bar for "fully supports CSS Grid" will be set even higher. They also mention that it might avoid "performance traps" where an implementation that needs to support all features of grid might be slower at some parts of grid layout than it would be if the specification were simpler.

If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.

nightpool
1 replies
3h43m

If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.

Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?

krsdcbl
0 replies
53m

my thoughts exactly - i think this points to a possible naming issue, since "masonry" is a relatively vague alias that does not really describe the underlying layouting logic, it just became ubiquitous enough for people building webstuff to understand because of that one jQuery plugin back in the days.

A better approach might be to lean on the "grid" naming, but still silo it off via an own display directive (a bit like "block" and "inline-block" have shared properties, but also mutually exclusive behaviours)

So maybe an own `display: flex-grid;` could be an interesting solution?

This separate layout mode would avoid "result-specific" nomenclature like "masonry", and could lean on both flexbox & grid to achieve that look: - using `grid-auto-flow` to set a "masonry axis" & distribution logic - using _either_ `grid-template-columns` or `grid-template-rows` to specify the "lanes" - and to make my frankensteinian display-mashup even worse (or genius! for you to decide), the grid items could in turn abuse `flex-grow, flex-shrink, flex-basis` to control their height/width within the main "masonry" axis

matsemann
1 replies
25m

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.

laszlokorte
0 replies
13m

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

qingcharles
0 replies
2h56m

It's great they're doing this. I've been nudging everyone involved with this since last year. The Chrome guys are the furthest behind (no support). FF has flag support.

I've been testing it since last year on FF and Safari and have no complaints about their implementations. I know some people are sniffling about the placement and naming of the properties. You have to be pragmatic about it, though, and realize there probably isn't a perfect solution and just implement it.

I refuse to use JavaScript for the fallback, so the fallback is a lot of ugly CSS that doesn't order things in the right way, but it doesn't make a big deal of trouble for the project I'm working on. Most people will fallback to JavaScript right now, though, and when JavaScript is your solution to layout then you're already on a loser.

jjcm
0 replies
9m

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

eyelidlessness
0 replies
3h10m

Either way, it's not as easy as it looks.

And exploring the tradeoffs might lead those exploring to reconsider their preferences going in.

Not directly related to the topic, but I recently did some prototyping on a second iteration of an interface with a similar tension—proliferation of similar but distinct types in a data model, or expanding the set of nuances within each existing type to support refinement within it. Going into that prototyping session, I had a very strong bias in favor of the latter. But after exploring the options, I found it vastly simpler to consume the “bloated” interface, and to reason about the resulting application code consuming it.

I don’t have strong feelings on the topic as it applies to CSS masonry, but I suspect there could be similar surprises in how people think about this tension intuitively versus in practice.

And while I think CSS in particular will have a hard time justifying “bloat” (proliferation of use case specific semantics), I think it’s possible that users do tend to find more difficulty using CSS’s denser APIs (like grid).

doctorpangloss
0 replies
2h35m

Is there a JavaScript polyfill today that can read the CSS properties in any of the proposed / implemented specifications that Just Works in Chrome?

bfgeek
0 replies
34m

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

aidog
0 replies
2h28m

look at the examples they made why it should be in CSS grid. I totally agree it should be in that. It's a form of grid. It should be part of CSS grid.

This is one of the layouts that were just impossible in CSS and we really need it soon. I also needed the feature they talk about with the background colors for css grid tracks in 2012. I solved that with DIVs, but it was hard to make it responsive.

m3h
14 replies
7h34m

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 top of it to provide the next generation of "masonry" grid, etc.

zarzavat
7 replies
7h20m

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.

baryphonic
5 replies
6h58m

No declarative language can ever handle every use case.

Prolog would beg to differ.

wizzwizz4
1 replies
6h4m

Prolog has well-defined execution order with side-effects. It's an imperative language masquerading as a declarative one.

baryphonic
0 replies
4h48m

MiniKanren, then?

baryphonic
0 replies
4h36m

This research is cool, but I always feel it needs an asterisk. Requiring a click or event or some external clock feels like a cop out. I've seen a similar thing with PowerPoint.

It would be a bit like saying a language with iterations but neither first-class functions nor recursion is Turing complete as long as an external stack is provided. Or maybe it allows a stack (or recursion) but requires external intervention for function application.

Cool hacking nevertheless.

seanclayton
0 replies
5h47m

So would LISP, Haskell, and Erlang.

PhilipRoman
0 replies
5h19m

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.

seumars
2 replies
7h20m

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.

m3h
0 replies
7h15m

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

That's good to know.

Terretta
0 replies
6h53m

Firefox masonry... by simply adding a new attribute that collapses grid rows

Not just Firefox, the proposal here is

    grid-template-rows: off;

meandmycode
0 replies
7h10m

I'm dubious that a constraints system would ever be considered, CSS has so far had some strong goals around it's predictably on layout cost.. that said, Houdini layout proposal is the closest to your comment, offloading layout to an isolated js context https://github.com/w3c/css-houdini-drafts/blob/main/css-layo... .. but honestly flex and grid, plus other things like containment have solved so many things for folks now that there's just far less demand for improvement than the days before flex

cnotv
0 replies
40m

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.

bazoom42
0 replies
7h18m

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

pquki4
11 replies
7h1m

I thought this kind of waterfall layout was cool and trendy a few years ago, but these days very few websites are doing it?

nkozyra
9 replies
6h54m

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.

thousand_nights
5 replies
6h31m

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

crote
2 replies
5h55m

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.

echoangle
1 replies
5h32m

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?

nkozyra
0 replies
5h28m

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.

nkozyra
0 replies
5h32m

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

SassyBird
0 replies
3h39m

Not the GP, but here is my website with photos with different aspect ratios. I used display:inline-block to achieve this result, effectively treating photos as text that needs to reflow.

https://yakubin.com/photography/albumless/

https://yakubin.com/photography/album/kenya-2023/

Proper masonry layouts which fill all available space in practice actually crop some images. Leaving space around photos is required when you don’t want cropping and want to preserve aspect ratio. That’s why I prefer my solution over what JS libraries for masonry layouts do.

whywhywhywhy
1 replies
4h25m

It's been called masonry before Pintrest was even founded.

nkozyra
0 replies
2h41m

I don't doubt it, but it certainly wasn't common web design terminology. Waterfall was one I encountered frequently.

crote
0 replies
6h1m

Yeah, it's quite weird to see such an obscure feature being proposed as a CSS standard. The demos just aren't convincing? Sure, I get the Pinterest application, but the other ones seem like a solution in search of a problem.

In the megamenu demo the multicolumn layout is pretty much indistinguishable from masonry. The only thing wrong with it is that it allows column breaks in the middle of content. That doesn't need masonry to fix it.

In the newspaper demo the multicolumn layout is actually better, because that's how newspapers work. The masonry demo becomes an unreadable mess.

The museum demo almost feels intentionally mis-designed. The CSS Grid 1 layout obviously has issues, but it could've easily been solved by pulling the nav bar out of the gallery, and using a multicolumn layout for the gallery instead.

So that leaves the Pinterest-style photo gallery. Sure, it's objectively better if you want to achieve this kind of style, but it's an outdated design with horrible UX. Why is it special enough that we need explicit support for it in the standard?

rezonant
0 replies
6h55m

A big reason is because it's not possible on the web, and it's worth noting that the kind of visual you see in masonry demos is the most extreme example of what you could do with it. Most of the time it's: I want to fill a page with modules of differing heights where positionality is based on importance not coordinate, without weird gaps where items fall into the same row and constrain each other.

chrismorgan
8 replies
7h18m

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.

rezonant
4 replies
7h7m

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 ignoring the raw ordering of the content and instead trying to emulate something visual, almost certainly some kind of hold over of the implementation as it currently exists.

ptx
2 replies
5h23m

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.

rezonant
0 replies
1h28m

Well no, the idea is that these are not related pieces of content. It's less of a newspaper article and more about independent items that are placed across the page. You don't have to follow the flow exactly as a user, but following the visual line is "more correct" than following through all of column A, then column B, etc.

amenhotep
0 replies
2h35m

My experience with it has mostly been on Flickr, and I hated it for this exact reason, even though that was mostly pictures not text. Sure, it's very pretty if you just want to look at the site and not engage with it in any detailed way, like professional designers seem to intend for us, but I always wanted to look at a page of pictures and scan my attention over them systemically, finding those that interested me, being distracted by them briefly, then returning to the scan and knowing where I'd left off.

Trying to do this with the "masonry" was horrible. What direction do you go in? Horizontally? Then how do you track which elements belong in which row, where you've already been? They're all interleaved. Vertically? Have fun scrolling down and down and down forever as the page loads more and more content dynamically. No, neither of those is how you're meant to engage, you're supposed to simply sit quietly and look at the big wall of pretty pictures.

Giving designers a non-javascripty way to do it is nice, I guess, but I really hope the effect is that the bad layouts we already have are at least better executed technologically, rather than that the better technology encourages designers to use bad layouts more often.

chrismorgan
0 replies
6h28m

The problem here is that users will look at the end result and see a series of columns, but that the use of masonry makes it not that at all.

I’m saying that masonry is risky if you’re using it purely visually, specifically because it’s purely visual. It’s the same deal with the CSS `order` property: it can be useful, but you have to be careful not to break expectations.

CSS is almost purely visual. There are a few cases where it influences the accessibility tree (e.g. `display: none`, `speak-as`, `appearance` in some user agents), but never in anything like order.

sebstefan
2 replies
7h7m

That's just a random demo. It's not particularly relevant for the concept they're trying to gather feedback on

chrismorgan
1 replies
6h40m

The demos should be motivating the feature. A bad demo is destructive to that effort. This is a very bad demo.

hombre_fatal
0 replies
3h13m

If you open the demos in a browser like Safari that doesn't support the feature, the demos remain as normal grid-aligned cells.

There I realize that masonry mainly works when your cells have such different heights that to grid-align them creates a lot of vertical dead space. Images and news blocks with images make sense for masonry for this reason and it feels good.

But text-only cells where the cell heights don't differ much, they seem better without masonry. The megamenu demo also works much better as a normal grid because they start with a header so grid alignment lets you scan the headers left to right easily.

A text-only newspaper could make sense with masonry because you aren't trying to navigate relationships between the items, and presumably the content can vary the cell height a lot.

codingclaws
7 replies
6h46m

I built a masonry layout with only CSS and HTML 10 years ago. The site is actually still live. A scripting language is used to generate the HTML and CSS based on the dimensions of the images. But the masonry runs left to right not top to bottom.

The_Colonel
4 replies
2h33m

That's not going to be responsive which is today a must have.

codingclaws
3 replies
1h51m

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

The_Colonel
2 replies
57m

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

CodeWriter23
1 replies
36m

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

The_Colonel
0 replies
27m

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.

thejohnconway
1 replies
6h39m

How does that differ from just setting the images to be inline-blocks? Was it justified?

codingclaws
0 replies
6h30m

It's centered basically. All rows span the same width, but the heights of the rows can differ.

turboat
6 replies
3h22m

Suppose we could create a backwards-incompatible system to replace CSS. How would we do it?

Are there any books or papers on how to create a coherent layout system?

What about alternatives like Qt, Tk, SwiftUI, etc.? I've never used anything besides CSS. Are any of the actually-implemented systems in the wild better? If so, what makes them better?

I want a system that provides a better interface for developers, but how? If we could start over, what are the design principles?

pphysch
1 replies
2h51m

CSS is overall pretty great and I've seen at least a couple non-web GUIs rip out their bespoke GUI systems and replace them with CSS or something very much like it.

I think the big change will be better support for hierarchical definitions, including but not limited to nesting. TFA discussion would be pretty moot if there were namespaced properties that could somehow fit under display: masonry; rather than polluting the global namespace.

turboat
0 replies
1h43m

I have to assume that's partly because of the availability of implementations, tooling, and developer familiarity. Many platforms will let you toss in a web view, and if you want to set up e.g. a configuration screen with text and toggles, HTML/CSS will get the job done, more easily than maintaining a custom system that's peripheral to the core purpose of your app.

I don't want to be overly negative, but I just can't view CSS as "pretty great."

I appreciate the inherent difficulty of using 1-dimensional static text to specify a 2-dimensional dynamic layout. Still, basically every programming problem involves defining abstractions over some domain concept and expressing that in the syntax of your programming language. Somehow that's harder in CSS than any other language I've used.

Within web dev I find both HTML and JS much easier to work with, despite their imperfections.

legulere
1 replies
2h45m

I think one classic book about it is "Rastersysteme für die visuelle Gestaltung - Grid systems in Graphic Design". Never read it though.

turboat
0 replies
1h34m

Thanks for the reference.

As I've been thinking about this, I do wonder if starting with grids as the foundation would have been a better approach. As I understand it, early CSS focused on stuff like color and font style, with primitive layout tools. Over time better tools have been bolted on, but it's messy.

Say we merged flexbox and grid into a unified system, and threw away the other layout algorithms. At the same time, made some tweaks to clarify margin, border, padding, and overflow. Maybe that's a good foundation.

mch82
0 replies
2h45m

Constraint-based layout using the Cassowary algorithm seemed like a popular alternative for a while (see https://github.com/slightlyoff/cassowary.js/?tab=readme-ov-f...). It’s designed to solve for variance in screen size and shape. Apple switched to Swift UI and may have moved on from this approach.

eyelidlessness
0 replies
3h5m

One thing to be cautious about when selecting prior art for reference is that CSS sets a high bar for declarative control. I can’t speak to any you mention in detail, but my sense is that more comparable prior art would likely be found in print use cases.

t_mann
3 replies
4h37m

I really like the general look and feel of masonry/waterfall layout, maybe it's because I grew up reading physical newspapers (and still do), but to me a columnar layout is just an intuitive way to divide up a page.

I just wish there was an alternative to the default masonry ordering, which afaik is a simple rule that goes sth like 'place the next item in whichever column it can go up highest'. This means that the left-to-right order is really juggled from the second row onwards. What I imagine would be really nice is if there was a layout that preserves more of the left-to-right (or right-to-left, if that's your preferred direction) reading flow. Something like 'put the next item one column to the right of the previous item (or in the leftmost, if you were at the rightmost), unless you can put a second item in the same column without the new bottom going too far below the bottom border of the column to its left'. This would be more flexible than strictly going left-to-right (which would also mess up alignment) and would reatin some meaning of the left-to-right reading direction.

I know it won't be possible to accommodate every possible formula one could prefer for masonry, but if you have content where the ordering matters at least a bit (maybe not for Pinterest, but for a journal eg it would), then I really think sth like this would be a more sensible default than the classic masonry rule.

tetris11
1 replies
4h31m

something like:

    {
       /* Move element a maximum of 2 columns left or right on update */
       grid-template-max-horizontal-shift: 2 col;
    }

mvkel
0 replies
4h21m

You could run into issues where you don't have enough content to plug the holes this way though, right?

For example if there's a gap that needs filling that Is 3 spaces away

amadeuspagel
0 replies
1h32m

I'd only use a masonry layout for something where there's no "clear" order anyway. I wouldn't use it for chronologically sorted images.

phkahler
3 replies
5h59m

Umm. Can't you just make each column a subgrid within a larger grid that has one row?

It seems like either these constructs are poorly designed, or people don't see how to use them to get what they want.

PullJosh
2 replies
5h53m

As I understand it, the hard part of a masonry layout is ensuring that items are laid out with the first items near the top of the screen and the last items near the bottom of the screen.

If you just plop your items into columns, the first items will all appear in the first column and the last items will all appear in the last column (left to right), which is not the behavior you want.

To my knowledge, the correct behavior cannot currently be created in CSS alone. (Or if it can, it must be a wild hack.)

phkahler
1 replies
4h11m

If people want to choose where things land they can do that. Therefore I assume we're talking about a scenario where the items are not known in advance - i.e. they come from a database query or similar. Is there no way to SELECT every Nth item when doing a query? Return a count and select where count MOD N = k? Dump those in a column.

This feels like "I want my layout algorithm to be part of the standard." and if you don't think so, see the part where they also want the equivalent of "colspan = 2" for some itmes - possibly with another pattern to define which ones.

micromacrofoot
0 replies
3h43m

"I want my layout algorithm to be part of the standard."

I mean, yes... it's a very common layout algorithm so it gets standardized

hwbunny
3 replies
3h40m

Webkit team snorting cocaine?

look at this, how intuitive, how readable:

grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch;

just throw the whole grid thing out of the window and get on board someone who can create syntax that wouldn't send you to jump off a cliff and feels like it was made by a fellow human being, not an AI controlled robot.

hombre_fatal
2 replies
3h8m

Well, at least show us your ideal replacement for that logic that's more intuitive.

Until then, these complaints usually cash out into unfamiliarity + assuming it's very hard to understand if you were you trying to understand it.

Declarative UI is a very hard problem, so it's not always going to be `text-decoration: underline`.

risenshinetech
0 replies
1h54m

Many things are hard problems, but you don't need to be an expert to recognize an obviously bad solution.

If you had showed someone the first bicycle, and it came with 3 differently sized wheels and a spike for a seat, you wouldn't have to provide an "ideal replacement" to know that it was a bad design.

hwbunny
0 replies
1h58m

FY, no free meal for you. These people are paid to do their job. You as a developer will suffer because of their idiocy. Protect them, you tool.

rezonant
2 replies
7h22m

Oh yes please. Masonry is definitely the missing piece right now. And I run into cases where designers give it to me pretty regularly-- I don't want to crush their dreams but without a JS-free masonry solution, the dreams are getting crushed.

OK, having read a lot more, here's my thoughts.

I love the possibilities that can be raised here when masonry is built into grid, but you can target specific rows and columns for specific elements in grid. This is a useful thing for some layouts, but when the rows are truly non-existent (unlike the related auto fill/fit stuff we've had until this point) I feel like the abstraction begins breaking down. As much as I love that we have Apple pushing to get this done, I do think it is probably better to go with a net new masonry display type :-/

mickael-kerjean
1 replies
6h30m

100% for masonry as well, couldn't care less about the approach as long as the selected one doesn't see the same fate as websql and it becomes a viable solution in a reasonable amount of time.

rezonant
0 replies
6h27m

Yes that's where I'm torn. I love seeing vendor interest either way.

But grid is already extremely complicated, and so easy to get wrong it's a meme at this point. Creating even more confusion about how it's fundamentals work feels like the wrong path :-/

victor106
1 replies
5h32m

this is very educational and useful

emadda
0 replies
5h8m

Thanks Victor, it means a lot :)

Unai
2 replies
4h16m

I really don't like how disingenuous, propagandistic and patronising Simmons is being in this article. Ending each section saying "all this will be impossible if not done the way I like", which is absolutely not true. There's not one reason why anything that can be done in "display: grid" couldn't be done with "display: masonry".

But I think, and I hope, that people aren't the fools she's taking us for, and can see how absurd her proposition is.

You could basically clone the grid specification, if you want all those features, and that way both can be developed with what works for each. She says doing that means new grid features might take more time to come to masonry. Really? More time than having to deal with new grid features that won't work at all with your version of masonry integrated in grid? You're still having to deal with two layout systems, even if you want to disguise one of them. Except doing it your way you can't select which system gets the features that work with it.

At the end, instead of two layout systems with two complete sets of features, we'll have one single layout system with a bunch of features that sometimes work and sometimes doesn't, depending on a particular value of a particular declaration that you'll have to know about. And that's why people hate CSS.

Seems lazy and an absolute mess to maintain. And it doesn't make sense at an intuitive level, since masonry works similarly to flexbox, not grid; and it doesn't make sense at a logical level either, since a masonry layout is not a grid.

But I guess this is what we'll end up getting, since apparently anything Jen says goes. Like the ridiculous idea of doing "CSS4", which means nothing, does nothing and is nothing, but we're going with it for some reason anyway.

troupo
0 replies
2h53m

I really don't like how disingenuous, propagandistic and patronising Simmons is being in this article. Ending each section saying "all this will be impossible if not done the way I like"

This is a very uncharitable way of reading this, and that's a polite way of describing this view.

She shows what is possible, and how existing grid mechanisms can be leveraged for masonry layout. It's implicit that coming up with a proposal outside the grid would need to accommodate the same capabilities somehow.

How is it patronising or disingenuous? They (and Firefox) literally implemented this and are showing what is possible. And are asking you for input. If you think you're incorrect, you can join and show them the error of their ways:

--- start quote ---

Our hope is that web designers and developers chime in (post to social media, write blog posts) with your thoughts about which direction CSS should take.

Some people, including those of us at Apple, like having “Masonry” be part of CSS Grid. We believe this functionality is a mechanism to expand CSS Grid — allowing it to finally create columnar grids as well as modular grids. And we want this functionality to be mixed with all the other features of Grid, including the powerful options for defining a columns, track spanning, explicit placement, and subgrid.

Other people instead believe Masonry should be its own separate display type. At first glance, defining Masonry with a new display type might make a lot of sense. You do get a tidy separation between layout types.

--- end quote ---

SigmundurM
0 replies
3h50m

I wonder, what theoretical features could we have for a modular grid that'd be fundamentally incompatible with a columnar grid, and vice versa?

If adding columnar grids to CSS Grids doesn't make any features impossible, then I don't see why we shouldn't just have one CSS Grid standard, and thus always ensure feature parity between modular and columnar grids.

The argument being portrayed by Simmons, as I understand it, is that every feature that currently works for CSS Grid's modular grids, would also work for a columnar grid.

sn0wleppard
0 replies
5h31m

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)."

slimebot80
1 replies
6h5m

Is there any examples of server-side rendering that pre-determines a masonary layout for the content?

Like: Given these images, and this window size, here's a calculated layout to make them all look nice...

I figure this would be more performant than any type of JS polyfill

echoangle
0 replies
5h36m

How would this work when loading the page the first time? Would you check the window size and reload once just to get the first layout? And would you reload the page every time the window is resized?

fmy105
1 replies
4h26m

The CSS Grid Level 3 proposal for masonry layouts looks very promising. The ability to specify a desired row height and have content flow into columns of equal width would make implementing common design patterns much easier. I especially like how this approach maintains the grid structure and allows for features like gap to work as expected.

One potential concern with the masonry layout is how it will handle responsiveness and different screen sizes. Will there be a way to specify breakpoints or change the row height and column count at different viewport widths? Ensuring masonry layouts are flexible and adaptive will be key for real-world usage.

The masonry-auto-flow: next property seems like it could lead to some interesting creative uses beyond the standard masonry look. Being able to control the placement of items and have them span multiple rows opens up a lot of layout possibilities. Would be great to see more examples exploring this.

It's good to see the CSS working group thinking ahead to Level 3 and 4 of Grid and gathering feedback from developers. Masonry has been a major pain point and commonly requested feature for years, so addressing it thoughtfully in the spec makes sense. Hopefully this is the first of many enhancements to come in future Grid iterations.

The comparisons to a potential alternative masonry implementation using display: masonry were helpful for understanding the trade-offs. While a separate masonry layout mode could offer some benefits, the simplicity and consistency of extending Grid is compelling. It will be interesting to follow the discussion and see which path is ultimately chosen.

presentation
0 replies
3h36m

Why would breakpoints be an issue? They’d just work the same as any other CSS feature wrapped in a media query.

account42
1 replies
2h24m

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

amadeuspagel
0 replies
1h30m

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

ThatMedicIsASpy
1 replies
6h49m

I already use this. On Firefox I just enable it in the options and make use of it for my bookmarks. On Mobile this isn't an issue since it's just stacked on top of each other (no about:config on mobile).

The last image has it turned off.

https://imgur.com/a/o7OyZEW

jamincan
0 replies
6h15m

From what I can tell, the rules of masonry layout result in irregular sorting since, from what I can understand, it fills by row the highest available slot first, but the result visually appears as though it's sorted in columns. So if you resize your window, the order of your bookmarks would change.

SassyBird
1 replies
3h8m

Reposting as a top comment for more visibility:

I have a website with my photos, which doesn’t use any JS for layout. When I was making it, I considered using JS masonry libraries, but I wasn’t satisfied with the results. Proper masonry layouts which fill all available space in practice actually crop some images. Leaving space around photos is required when you don’t want cropping and want to preserve aspect ratio. The only way not to do that is to have infinite scroll, which I guess is what corporate addiction machines want, but that’s not what I want on my own website. Here is what I did:

https://yakubin.com/photography/albumless/

https://yakubin.com/photography/album/kenya-2023/

I used display:inline-block to achieve this result, effectively treating photos as text that needs to reflow into new lines. I’m very satisfied with the result and prefer it over what the masonry libraries do.

datagram
0 replies
1h37m

Flexbox was designed for these kinds of layouts, so that would also be an option here.

thebeardisred
0 replies
1h39m

If this leads to more "forever" scrolling pages where I can never get to the footer I'll lose my goddamn mind.

spintin
0 replies
1h15m

You can very simply do this with javascript.

Browser developers are now reaching for straws to remain employable.

That said the biggest tasks remains:

- Go back to HTTP/1.1 with "One time password" auth.: https://datatracker.ietf.org/doc/html/rfc2289

- Simplify the browser so that it can be compiled in less than many hours on the latest CPU.

- Completely remove the tie-ins to any commercial/governmental entities.

Basically go back to Netscape with some improvements to javascript performance and hardware accelerated rendering of HTML.

Everything else invented in the last 20 years is meaningless. This is valid in most domains: Raspberry Pi is the only real exception.

specialist
0 replies
3h0m

Neat. I like it.

Out of curiousity, why don't browsers have pluggable layout managers? Like Java's AWT/Swing LayoutManager. [1]

Fussing with CSS and Java's stock layout managers (gridbag, table) always fills me with frustration and anxiety. In my experience, for the fussy work, it's easier to explicitly code what I want.

Ages ago, inspired by Designing Visual Interfaces [2], I made a layout manager [3] for canonical design grids [4].

It was pretty neat. Fluent API. Always visually correct. All the baselines aligned just so. Predictable results. Perfect for banging out CRUD forms. [5]

1/ https://docs.oracle.com/en/java/javase/21/docs/api/java.desk...

2/ https://www.amazon.com/Designing-Visual-Interfaces-Communica...

3/ https://web.archive.org/web/20110302212909/http://java.net/p...

4/ https://web.archive.org/web/20110308034949/http://designgrid...

5/ https://web.archive.org/web/20110515182322/http://wiki.java....

roblh
0 replies
30m

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!

pimterry
0 replies
7h27m

For more background, and some detailed discussion of the opposite argument ("display: masonry" over "display:grid"+"grid-template-rows: masonry") see https://github.com/w3c/csswg-drafts/issues/9041

pimterry
0 replies
7h37m

A really nice feature here is that if you view the demos in a browser that doesn't support this (i.e. all current stable browser releases without special flags enabled) because they're building directly on grid layouts, they still appear in a pretty reasonable fixed-row format: https://webkit.org/demos/grid3/.

In each case it'd look much nicer with a proper masonry layout but it's still very usable otherwise (and of course you could feature detect to provide a better fallback if you're not happy with that anyway).

paradox460
0 replies
1h4m

It feels good to see the webkit team actually doing good, publicly visible work again

When I was cutting my teeth in web design, the early webkit blog and safari releases were always inspirational. The rate at which they pushed out new features in the mid 00s was astonishing

nofunsir
0 replies
3h43m

No thank you. I just want all the whitespace to take a hike. I certainly don't need this layout if webdevs are just going to put all the content on the center 1/3 to 1/4 of my screen.

lovegrenoble
0 replies
6h58m

I always preferred to use Flexbox on almost everything; it's suitable for most situations. Also, for anyone struggling

with flexbox - I use this tool to streamline the process: https://flexboxcss.com

jmull
0 replies
1m

Feels like a special-purpose layout that more properly belongs in a framework than CSS.

fzeindl
0 replies
24m

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?

egypturnash
0 replies
4h10m

I feel like I spent this whole proposal waiting for "grid-template-columns:masonry" to be discussed.

cnotv
0 replies
46m

I evaluate the CSS updates based on the gap in masonry layout achievement. It's one of the most important layouts that have existed for more than a decade and should have been the only achievement after flexbox and grid. If you have a bunch of media, unless you have a narrow container like FB/IG, that's the only way to go. The alternative is fixed ratios. Anyone who has been working in FE knows it.

branmcconnell
0 replies
5m

I’ll admit that I was skeptical at first about including masonry and 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 grid properties (columns/rows, gap, etc.) from a CSS Grid.

aidog
0 replies
2h32m

I absolutely want this. I have wanted this for years. This is a form of grid so it should be in CSS grid. Especially since it has tracks. Browser makers, please just ship this.

Onavo
0 replies
3h34m

Can you add drag and drop to this? Currently you need libraries like https://gridstackjs.com/, especially for nested cases.

KwanEsq
0 replies
6h9m

Nice to see this getting some push and attention. I still remember seeing Mats Palmgren (seemingly?) single-handedly proposing/speccing and implementing this in Firefox a few years ago. Glad it hasn't just died because it was a Mozilla proposal/experiment (with proper experimental stage), instead of something Google just dumps on the web fait accompli.

6510
0 replies
5h30m

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.