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).
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.
Quadratic performance is a bit of an exaggeration. It's not O(N_items^2). It's N_tracks x N_items, and basically nobody has N_tracks ≈ N_items. Practically speaking, the upper limit is closer to (N_items^1.5) because N_tracks is unlikely to go over sqrt(N_items) in cases where N is large. And almost all of those layouts will have repetitive track sizing patterns, so they can be optimized to a much smaller N_tracks that approaches O(N_items).
Why does this require checking every item in every column? It looks like the layout algorithm greedily picks the column with the least total height so far, every time it adds an item.
The examples in the article seem to have CSS that directly sizes the columns, albeit with some flexibility such as being able to change the number of columns to better fit the width. It seems like the item widths depend on the column widths, rather than the other way around (which seems like it'd be circular). What's an example where the column widths depend on the items?
You first need to decide how big each of the three columns are going to be, then you want to place the items in each of the columns.
Depending on the non-fixed column type (there are different rules for each type) you want to ensure their constraints are satified (typeically they are big enough to encompass the items).
Thanks, that helps; I'd thought about variable numbers of columns based on the width of what they're contained in, but hadn't thought about the possibility of wanting to choose the number of columns to fit their content better. Mostly because I was imagining content like images that can be scaled or text that can be wrapped, rather than fixed-size content or content with a minimum necessary size.
Grid has a rich functionality for autoplacement of items and one of the arguments for masonry being part of grid is that you can easily mix the two positioning approaches
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.
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
> And yes, while making CSS Grid more complex will make it harder to extend in the future, we believe there’s an advantage to having these two types of grid layouts intertwined. This way the CSS Working Group will always define all new additions for both modular and columnar grids. There won’t be something added to display: grid that will be left out of display: masonry, or vice versa. For example, many developers want CSS Grid Level 4 to provide a mechanism for styling grid areas and grid lines — perhaps a way to add a background color to a track, or create a rule line in a gap. It’d be great to ensure that will work for both modular and columnar grids from Day 1.
> By using subgrid, we can put the year and catalog number on the right of each card — and line up this data for one painting with the same data for the other paintings.
The downside is that all the parts of grid that might be useful in masonry would have to be duplicated in slightly different ways.
This together with the fact the the only two current implementations use display: grid
If it is possible to make them perfectly compatible then the main negative side
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...
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.
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.
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 would suggest that `display: tetris;` is implemented such that each row SHOULD have whitespace, and if at any point a row becomes fully occupied, a conforming rendering agent MUST remove the entire row.
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!
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.
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.
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.
Does it require a ::last-child hack to get working? I’m a fan of grids when it comes to heavy writing content like I mentioned but I still don’t think it should all be packed in the spec.
That will make the child items 180px wide, repeat as many children in a row as needed to fill the width with a gap of atleast 1rem extended so that the items are justified to the left and right and are spread evenly. The last row has however many children are left with those children positioned to match the rows above.
Ah, ok. I wasn't able to get the last row working right with flex, but didn't experiment too much as the CSS grid approach worked. You could look through the other answers in that StackOverflow question.
I have. It’s a mix of people saying it’s can only be done with CSS grid semantics and then a few who prove them wrong with flex box. Reinforcing my above question about “why not :after? :last-child? And flex it into shape?”
But I get it. Grids are easy to grok and grid.css is for the birds. Bake it in. Bloat the spec. And allow pixel perfect precision with one (or two) less div.
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)
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.
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.
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.
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.
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.
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.
Well, the idea with this layout is that there isn't really an inherit order to the children. You would use it where it doesn't matter which order you 'read' the items.
If the order was important, you would use a 1D or 2D layout.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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:
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.
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)
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'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
Oh man - I remember attending a CSS meetup in like 2014 at the Google offices in Sydney where someone from the CSS WG presented Houdini Layout. I would be surprised if that ever ships.
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.
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.
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.
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.
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).
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.
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
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.
Some people want to go systematically over the items when exploring. I certainly tend to operate that way, and it’s infuriating when the UI is making it difficult for no good reason.
Not sure why you’re being downvoted, it’s true. If you want to display items (normally images) with different dimensions, while respecting their natural height/width ratios, you really have 2 options:
1) Fixed height rows: lower information density (excess white space around some of the items), but easier to scan systematically
2) Masonry layout: higher information density (no excess white space around items), but harder to scan systematically
Nobody is “right” here, it’s simply user-by-user preferences about what you prefer.
It doesn't even make efficient use of space because the size of items depends on their aspect ratio. Fixed size cells is a much more sensible approach.
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.
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.
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."
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.
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?
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.
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.
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.
I would hope we're getting over trying to make other websites look and behave more like Pinterest. Pinterest exemplifies the worst of the web in several ways.
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?
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]
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!
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.
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.
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).
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.
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?
"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...
> 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.
For what it’s worth, I found masonry layout always detrimental to my use of a site. I would prefer CSS not to encourage it by providing built-in support.
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.
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.
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.
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.
Well-known == highly visited == native implementation will have large accumulated impact on end users (their performance, energy consumption, improved usability ...).
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.
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.
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 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 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
I never understood why CSS would not just adopt Apple's Autolayout and be done with it: I want to specify that this space should be equal to that space, these borders to grow, and those borders to shrink and this point always aligned to that point.
It is simple, intuitive, it works for all cases. Instead we are inventing, what, the fifth generation of CSS-layouting now? Does nobody think this is odd?
It's 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.
Checking that the layout isn‘t exponentially complex and DOSing the browser could be a simple task for the web developer. If you want your website to perform bad you can always find a way.
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.
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?
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.
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.
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.
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.
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…
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 :)
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.
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.
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).
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.
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)
I was referring to the document still having the semantic structure. E.g. masonry.js also supports relative sizing, so it doesn't need to know the screen size beforehand.
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.
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.
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.
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 ;)
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.
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", 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 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.
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.
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.
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 :-/
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.
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 :-/
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.)
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.
> 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.
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”.
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.
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.
> 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.
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
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.
jQuery has a fluent interface and often shorter/smaller/more convenient APIs on top of that.
DOM APIs are quite literally 90s era Java-style APIs.
While DOM APIs have pulled in a few niceties over the years, some of them are really anemic (e.g. querySelectorAll does not return a proper Array-like object). Worse is combining them. Almost every API is a single-shot tedious step-by-step chore.
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.
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.
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
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.
> 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”.
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.
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.
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.
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.
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)
"Dry stack" is another term for that, a stone wall without mortar.
In my opinion, thinking of this as a grid is misguided. It's barely different than flex columns. I would want to be able to have some objects take up more width than one column, or not have clean columns at all. Like "space filling" and "mosaic".
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
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.
reply