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

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

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.

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

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

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.

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.

It seems like the precursor to this was the whole "Help choose the syntax for CSS Nesting" thing that happened a while back. Browser vendors couldn't figure out the syntax, so they asked the 'wider public' which they preferred https://webkit.org/blog/13607/help-choose-from-options-for-c...

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.

> new proprieties

I'm guessing this was going to be "properties"? It kinda looks like "proprietary" instead, so let's double down on that - I propose "display: tetris;"

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

I've yet to ever find a use case for grid.... I'd prefer this be a flex box feature so I can continue ignoring grid. But it seems like they have good reasons for including it, so I suppose I'll have to actually practice with grid more!

Masonry is easy and has already been solved using CSS Multiple Columns:

    .masonry {
      column-count: 6;
      column-gap: 10px;
    }

I don't know about the implementation but it makes zero sense that masonry should be part of grid. It's not a grid!

If there is a debate, who is pushing back? Or is it more about details while every vendor is supportive at high-level?

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.

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.

Focusing solely on sighted users, I think the current ordering makes sense. What you propose would require often scrolling up and down to view the items in order, and would have large layout shifts if more items are added.

Why not just use widely supported CSS Multi-Column Layout for masonry effect?

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

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.

It's the left-to-right ordering that's the problem. I'm fairly sure there's no way to order things left-to-right in this layout without inevitably having to skip around haphazardly.

In a magazine-style layout, wouldn't you read the columns top-to-bottom first, then left-to-right? You can accomplish that already in CSS with either 'columns' or vertical flexbox.

Another issue with this 'masonry' layout is the ragged edge at the bottom. In a magazine that would presumably be justified -- again something you can do with columns or flex.

On the web, I guess there's a hidden assumption that you'll have endless scrolling content, so it doesn't matter what the bottom of the page looks like? If so, that's not necessarily something that should be encouraged.

something like:

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

Not particularly anti-css, but you may be interested in concepts like size groups, properly predictable size-request-allocate cycle, width-for-height, constraint- and align-based layouts and in generally cleaning up the mess of non-orthogonally connected ideas in css. More explicitness and separation for properties. Remove bs like negative margins, make all distances multi-level, e.g. padding = max(el.paddings[]). Make bounding boxes explicit, make borders proper elements, etc. Boxing isn’t a bad model, CSS is just an awful implementation of it. Absolutely ridden with fragile incantations and absurd limitations which bring more issues and “solutions” that will break 99% of the times you touch it.

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.

This would be such an interesting write up comparing many styling/layout systems! Unfortunately I reckon not many people have experience with multiple styling languages, so not many people can create such a write-up.

I think flutter and XAML might be other interesting ones to look at

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.

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

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.

You could probably have done this layout in a couple lines of CSS with a row-oriented flexbox that wraps and is center-aligned. That would be the more standard way to do it too.

I don't use JS for masonry layout. I have a fallback from the current masonry CSS solution to a supported CSS solution.

The problem is ordering. The current CSS-only solutions work fine as long as the order is not important. (though you will still end up with weirdness at the bottoms of the columns IIRC)

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

this is very educational and useful

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

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.

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.

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.

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

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.

Try Firefox beta on mobile :)

They've definitely brought in some new people. AFAICT the reason Safari even has Masonry support is because they brought in the (very talented) guy that wrote the CSS spec for it.

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

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.

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.

You can make something very close, but you can't order the items the same as you can with the new property (so if the order is important this might be a dealbreaker), and IIRC you end up with less attractive, more-jaggy bottoms to the columns.

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

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

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?

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

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.

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.

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

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

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.

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.

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.

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

I have it on my website (https://packagepicker.co) in only CSS by using `flex-direction: column` and setting a best-guess max height with several breakpoints. Unfortunately it does break down in some situations because some pages have many fewer selections.

My order doesn't super matter but I do like to maintain it. I tried for a long time using CSS columns but I didn't have good luck with that either, though I can't remember exactly why

> it works for all cases

It's only a fixed 2d arrangement. It isn't any more expressive than the CSS table layout or position absolute+relative combos. It has no ability to react to size constraints in any other way than naive stretching and hitting min-width hard. It can't do anything "responsive" like wrapping items to the next line, or switching a grid from 1x6 to 2x3.

You can't make masonry in autolayout constraints, other than precomputing specific constraints for every item, which won't automatically reflow the items to a new container width.

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

Yes, masonry has been already solved using CSS Multi-Column Layout: https://w3bits.com/css-masonry/

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

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/

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?

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

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

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!

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

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

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

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

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.

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.

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

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/

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.

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.

"masonry layout" is a term used for at least a decade[0] Pinterest is probably the most famous implementer of this layout

[0] https://www.sitepoint.com/understanding-masonry-layout/

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.

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.

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

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

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

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

Might be ok for a footpath?

If you read it to the end, you'll see their note on the name. That is also something they want up for debate.

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

Thank you. I was confused as well.

A name for the inverse I suppose

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

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.

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

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.

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

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.

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

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

Is this a sysvinit vs systemd rant?

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

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

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

You can say that about almost any abstraction layer

Nixos?

Um, err, POSIX.

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