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.
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).
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.
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?
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.
Related: I created an interactive demo of grid principles here:
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.
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.
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
I think it's really weird that this is considered. Masonry is a very specific layout implementation whilst the typical CSS layout feature is more foundational.
Also, I think the need for masonry is vastly overestimated or perhaps not fully researched. It is presented/implied to be a common need but it isn't. Check the top 100 websites, check your personal top 20 websites, how many use masonry? I bet not that many, it's niche use case which also has plenty of usable alternatives. It also never even shows up in any developer surveys.
Anyway, if we're into the game of building very specific layout solutions into CSS itself now, I'd argue the layout as seen on Google Image search is the far more useful one. It is somewhat of a horizontal masonry, but not really. Each image must keep its original aspect ratio (no cropping) whilst all images on the same row have the same height, thus filling the vertical space of the row fully. At the same time, rows must be roughly of the same height. There can be no gaps at the end of a row nor at the last row.
Quite hard to implement, although there's articles describing how.
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
I absolutely hate this kind of layout, especially when combined with infinite scrolling. Makes it impossible to systematically go over all items.
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
I’ll admit that I was skeptical at first about including masonry in the CSS Grid spec.
After reading through the article, I’m convinced it is the right path forward, allowing masonry layouts to utilize the same APIs and properties (columns/rows, gap, etc.) as CSS Grid.
This would lower the bar of entry by using familiar APIs and allow simpler switching between masonry and other column/row setups responsively.
```css .example { display: grid; grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); grid-template-rows: auto; @media (width > 500px) { grid-template-rows: masonry; } } ```
I thought this kind of waterfall layout was cool and trendy a few years ago, but these days very few websites are doing it?
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....
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!
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.
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
Feels like a special-purpose layout that more properly belongs in a framework than CSS.
Caveat: I know nothing about this, but have some experience with grid and flexbox.
To my mind flexbox could be a basis for masonry way better than grid with less overhead.
I also think mosaic would be a better name.
"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...
I do it on my portfolio site (https://www.bennyschmidt.com) in JavaScript by maintaining a `colCount` with each column just being `flex-direction: column`.
But after seeing this I should switch to using CSS. Didn't put too much thought into it, but when I realized it wasn't immediately simple in CSS grid just did it in JS.
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?
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.
If this leads to more "forever" scrolling pages where I can never get to the footer I'll lose my goddamn mind.
def. grid: a network of lines that cross each other to form a series of squares or rectangles.
Masonry layout doesn't form a grid, but multiple columns with a variable item height.
I feel like this should not be a part of CSS spec, and absolutely not a part of CSS Grid.
If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?
How can there be an “inventing masonry” section without a reference to the masonry js library[1] - I suppose this is where the name comes from?
The vertical layout is simple to implement. Horizontal is much harder, and more useful for media like images and videos, see Flickr. None need CSS. And, if you are going to do it in CSS, you better handle both, not just the easy less useful variant.
CSS is such a failure. Grid is the 3rd or 4th iteration of layout methods and still you need to think this much about how to code a layout? This is the most basic thing in UI and we've been doing it for 3 decades.
Can you add drag and drop to this? Currently you need libraries like https://gridstackjs.com/, especially for nested cases.
This is readily achievable today with `columns`: https://primozic.org/aesthetics-art
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.
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.
I feel like I spent this whole proposal waiting for "grid-template-columns:masonry" to be discussed.
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.
Looks convenient, but another step towards a monoculture internet. :(
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.
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 :-/
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.
> 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.
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.
[flagged]
[dead]
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.
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.
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.
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.