Masonry mega menu is one of those things that the customer wants and you always have to do quite the math to try and figure out what goes where to temporary arrays in arrays and then recalculate that on window resize when it gets below or above certain thresholds. I’m glad this might come soon natively
Masonry deserves its own display type for sure. Developers should be able to have some comfort knowing they've conquered block, flex, grid and masonry separately. I remember the hell that existed when browsers did not agree, and I don't want to return to that by convoluting grid further.
The other problem with "off" is it fails the "least surprise" test. Turning something off you don't expect to unlock a whole new layout type with a bunch of custom options
I feel like a lot of commenters are either not understanding how things are ordered in a masonry layout or just going with various variations of "but why don't you just solve it using a lot of complicated CSS+JS work instead!" Like… Noone's forcing you to use it, and the same could be said for Grid. Why would any of us want to make layout with anything but tables and FRAMESET? One of the best things with modern CSS is that it conforms to the kind of layouts people actually want to do. We don't have to do float:left and margin:left anymore, or margin: 0 auto for centering. Making completely normal layouts doesn't feel like solving a rubik's cube. And it shouldn't.
@@GerrodNoordsylovesu You'd think anyone who's been around webdev for more than a few minutes would know by now there is no job security =) Or, if there is, it can only be achieved by being ready to throw out everything every few years or so and learn everything from scratch. =)
Easy to explain: Masonry layouts are often used for endless-scrolling-pages, which means lots and lots of items. More items = more work a JS solution has to do = endless-scrolling-pages grow significantly slower the further you scroll down. Make it built-into the browser, and it will be much faster. Everybody wants that!
Yeah, I mean as an old school web dev, I can say that there is pretty much nothing in modern CSS that you couldn't do 20 years ago with CSS+JS, it was just a major pain in the ass and a minefield of browser compatibility. While I do find a lot of newer css features somewhat superfluous, I appreciate greatly that now you can sometimes do in a few lines of CSS what used to take sometimes hundreds of lines of difficult to debug javascript.
Both Jen Simmons and Rachel Andrews are such legendary figures in CSS. I have been a FE developer for 15 years and I learned a lot from their articles and videos, that this feels like I'm watching my aunts fight.
The unintuitive order seemed intuitive to me: you're trying to even out the heights of each column, which this does by always adding the next item into whichever column is currently the shortest. I don't feel like it's appropriate for something like the footer menu example since a user is more likely to expect newspaper column order and expect the submenus to maintain that order across devices, but it works well for things like galleries of non-sequential images.
7:46 It isn't unintuitive, it just tries to fill up the shortest row, which is exactly what masonry is. Having said that, masonry has to be its own display type. If the concern is that the features grid has are also useful for masonry and visa versa... just implement them for both. The people responsible for the spec should just adjust both when that makes sense. The fact that Apple claims most of its demos wouldn't be possible with alternative proposals, while Google has to point out that all demos very much would still be possible also just seems scummy behavior and an attempt at FUD from Apple's side.
You also have another issue. Standard shift. People will likely request more features to Masonry, and some might actually be incompatible with Grid, so you end up having bloat in the design specifications, and some really annoying "Oh, but that works here, but not here, but it's the same thing!" kind of behaviour, which we see everywhere in CSS already. I mean, you already have keys that doesn't work unless you are Masonry in the first place, so why should Grid have added to it?
The problem with doing it as part of CSS Grid is that the whole spec assumes it's styling a _modular_ grid, so a bunch of the rule work in ways that only make sense for modular grids - grid-template-rows is a great example of this: the way the rule works when you set it to "none" is not to have no rows, but to have no _explicit_ rows (meaning you still have rows). Unless the _entire_ CSS Grid spec is going to be changed to accommodate the fact that grids can now be columnar, it makes no sense to have masonry as part of that spec.
I did masonry layout recently and it was pretty easy with one trick - just set layout to grid and set item's `grid-row: span` to item's height (in whatever unit,). It doesn't cover all cases but that's basically it
I legit didn't know I needed this until I saw the mega menu example and realized oh my goodness, I just did that manually last month for one of my projects.
For the "weird" order of images in masonry, that's actually exactly how I want it to behave. On my photography portfolio website I don't really care where every picture is horizontally, I just want control over the vertical order.
I initially thought the Pinterest-like image layout was too niche for adding it to CSS, but I have to admit seeing all the use cases (mega menu, etc.) makes it super appealing
One obvious overlooked application are any type of page with many options/fields contained in arbitrarily long sections: Option/settings pages, Dashboards, CRM, ERP, CMS, ... Current layouts will waste a lot of space for such applications. With masonry we can efficiently use all of the space on desktop, and degrade gracefully to single column on mobile, all while retaining a somewhat intuitive order for the individual elements while resizing.
regarding the order of photos in masonry (see around 7:35), I believe the "traditional" idea here is that they are ordered by their offset from the top... so once elements have filled the width along the top, the next element will try the next highest available "column", resulting is 6 being below 3, 7 below 4, 8 below 6, each time because the selected spot is closest to the top of the view.
More flex-y than grid, but more grid-y than flex. I can understand the want to not build on the tech-debt of Grid's existing implementation complexity, I also think "subgrid" doesn't have a place in Masonry. It'd be good to be able to re-use as much syntax and phrasing as possible, I share the dissent for "off". What if Masonry (eventual name can be discussed, though "Waterfall" suggests only downward, so not fitting imo) used "*-template-columns/rows" and "*-direction" and we generalised some terminology like we have done in the past?
Sure "waterfall" suggests something going downwards... But wouldn't that be the direction for this type of layout 99% of the time? Because horizontal scrolling is fairly rare, and generally requires you to mentally rotate and flip everything from the normal behaviour anyway, so I think we'd be able to handle "horizontal waterfalls" in those rare cases. I quite like the term "waterfall" because it suggests the direction of flow, from top to bottom in parallell, while masonry doesn't imply flow at all; but rather implies something very rigid and static with usually bricks that are stacked so that vertical gaps are _not_ aligned. If anything masonry implies something being build from the ground _up_ in horizontal layers rather than from the top down. (And in fact when I clicked this video; I was imagining a table full of cells with colspan of 2 and I could not understand how that was anything new.) Also "waterfall" is a much more elementary word than "masonry" so it's much more likely that second language speakers have heard the word "waterfall" than "masonry". And it's already a common term in many countries for this kind of layout.
If flexbox is grid or grid is flexbox, then masonry is grid. Flexbox, grid, and masonry are all very similar and related, but fundamentally different imo. Whatever makes it simplest and most intuitive for people learning and writing CSS imo.
The layout algorithm positions items from left to right, placing each one at the highest available spot. Initially, the first X items are placed at height 0, so they line up horizontally. If, for example, the second item has the shortest height, the next item (N+1) will be positioned directly underneath it, creating a balanced flow.
I think I agree with ur final statement: im leaning towards the "display: masonry" method, but would be fine either way as long as it just gets there :P
30:48 About that, it seems like what we saw Apple did (when we saw the numbers) involved going left to right at equal y positions, and going for the first fit otherwise. Each time, the topmost slot was the one that was filled, so that was likely done in a single loop. Of course, we start to see more complex algorithms when images span over several columns, but even then, it wouldn't imply processing every possible layout. In the first place, once the width of the image is known, the height is also known using its aspect ratio. That means no "trying every possible way to get measurements", it's not an n² problem, more likely to be some sort of n log n.
7:20 - The "one weird thing" about how the browser is doing it is probably by placing N columns and looping over them sequentially, each time keeping track which column is the smallest height and placing the image there, then repeating the loop for each image you need to place. You can notice #1 to #6 are the top ones, #7 is placed right after the shortest image and then #8 is placed after the second shortest one. Then the shortest column for #9 turns to be the one starting with #4 and on and on... (at least that's what I think and how I would have done it - I don't even wanna know the pain of optimally re-rendering it on window resize.)
I think one additional benefit of masonry over grids is that it becomes more accessible, each item having a dynamic size makes it easier to remember where on the page a piece of information was, as opposed to everything being a samey height and width.
I haven't done one before, but I think the menu thing is easy enough to do with normal flex layouts by transposing the content order. The case for the endless scroll masonry thing is the use case that is harder to emulate, because with an undefined amount of content you can't precompute the transpose.
The algorithm for selecting the next placement spot appears to be you place the next image on the shortest column. A few years ago I wrote an algorithm for placing images in a way that balances the left to right top to bottom griddy ordering with even column sizes. I wonder if they would accept algorithm suggestions
This is basically a more efficient way of doing the "gallery dense" CSS styling. And has a bit more styling options like removing all blank space, but still, this is layout is achievable so I don't understand the emphasis on how hard/impossible this is right now, because it's not: note, went and read webkits blog and I see the use case this is intended for more than just images. Their reasoning is solid for display: grid and have put far more effort and thought into their blog and argument to support it than Chrome has with theirs. I very much support including it to the grid layout.
The menus are nice and definitely a valid use case for masonry, but in my opinion, they've been pretty simple before with flexbox. All you'd really need to do in your media queries is change the order. Perhaps I'm just not understanding though. It's admittedly been a while since I've had to make a menu like this.
I think adding it to grid adds complexity, which gives the biggest argument of all: how easy is this to teach to jr devs? display:masonry gets my vote because explaining display grid was already a time sink.
The best alternative to masonry I've seen is the 'break the grid' solution: you first align items on a grid, and then you systematically offset them with negative margins. This sucks because it requires the use of magic numbers or js to calculate the negative margins. If masonry === "break the grid", then it feels both weird (why 'break the grid' if we don't want it in the first place?) and not weird (grid as 'baseline' for 'broken grid' behavior) to make masonry part of grid... I'm not sure which camp I lie on, though I like the "grid as 'baseline' semantics of masonry" idea.
gotta say I'm leaning towards separate. just the fact that you're not cluttering and convoluting the already messy grid stuff means its also definitely more easily extensible for updates
display: masonry makes ways more sense to me. I'd say that the difference between grid and masonry is similar as between flex and grid. Both flex and grid naturally order elements as a wrapping row, but grid has added logic for enforcing specific horizontal spacing (i.e. columns). Masonry is similar to grid in this regard, but it's different from both flex and grid in how it places elements in the columns - instead of putting elements in consecutive columns, it prefers to skip the columns if it levels the bottom better. If another ordering gets available (e.g. column by column, better for this menu case) it still will be something that is kinda similar to both grid and flex, but close to neither.
My question is, what are developers switching between the most? Are they going to start with flexbox and then want masonry? Or start with a grid and want masonry? Everything is an abstraction at the end of the day, so deciding what things are really about is based on the job to be done, and determining the boundaries of the job to be done is usually best done by looking at what people see as substitutes.
Google really struggled to implement subgrid in a timely fashion so they might be worried about history repeating itself there. As someone who mostly works on technical webinterfaces and not user-facing websites I do have a major use case for subgrid (a concept I call soft nesting) but not for masonry. Edit: After seeing their side of things, honestly I'm with google on this one. Masonry should either be a seperate layout or an extension of flexbox. Implementation wise, masonry has little in common with grid.
I made a masonry layout with some basic CSS and like 8 lines of JS for a reddit gallery front end i was working on. While it was a pain in the ass and its not perfect. Im excited to see this be implemented in too the CSS standards.
I'm on the other side of the fence. I usually side with google when it's about web standards, but I prefer apple's approach so much. Especially when it comes to feature partiy. Subgrids in a masonry layout would be so dope.
Honestly, if I had to pick one Google version is a win. But I'd choose not to have this on the css spec. I've used and depended on masonry a few times but i feel it's very niche. Different from flex and grid, that i was using even before all browsers actually behaved well with them.
I just want this: `grid-template-rows: repeat(3, 1fr) masonry 2fr;` If this is done with a nested subgrid that can be display masonry, I’m fine with either option. ``` display: masonry; grid-template-columns: subgrid; ```
I definitely went into this thinking it should be a separate display type exactly for the reason Apple highlighted, it doesn't align in both dimensions. But their examples prove to me that the benefits of adding to grid are huge, and that they are also compatible concepts. Making it a separate concept would only be a downgrade in functionality, most especially in the future, I don't think restricting the feature to not allowing mixing fixed and intrinsic layouts is a good idea since that's doesn't even really represent the majority of waterfall implementations already on the web. In terms of complexity for web developers, it looks like it's easy enough to just use a demo website to figure out a layout you want, copy paste the CSS, and tweak from there. People already do this for current CSS grid and flexbox, and lots of other CSS. I don't really buy a lot of Google's implementation or performance complexity complaints. Firefox and Safari already implemented it no problem.
@@futuremapper_ And making sure the spec has sections that directly relates to what you need, instead of half the keys being unusable due to using a specific feature in the display type.
It will look unintuitive to see which goes where but I think it's because they are counting in terms of left to right and then closest from top then down to bottom
2:50 but it's doable with CSS. You just have a small enough grid and you decide over how many squares each image will sretch. No javascript required. You can have individual images break out into multiple rows and multiple columns around them and you can have the next images not doing that and instead following equal amount of columns and rows.
But is it dynamic across different resolutions ? That is, can you define it to look good on all resolutions without using multiple definitions (aka using media queries) ?
firefox does btw. already support "masonry". In testing versions it's enabled by default and in stable there's a feature flag to enable it Chromium is the only platform that DOESN'T support it
To avoid confusion, we should just call it display: flex-grid; Simple, descriptive, I can't foresee any issues. Really though, at first I was really into having it as a part of grid, but over the course of the video it's clear a new display type makes a lot more sense. It really will be a 2d flex more than a grid. Definitely don't like 'masonry' as the name though. I guess it makes sense, but it's not immediately obvious. Not sold on waterfall either. Naming things is hard.
I was about to ask mid way through, what does w3 group say about all this? As usual, "why not both at the same time, and let them figure it out". I swear, they're so Switzerland and I'm almost thankful for it. I'm team display:masonry personally. It's easier to mirror grid code where needed, than it is to fix defunct conflicts between two similar standards.
I think masonry should be optional feature of either display:grid or display:flex. I would personally prefer flexbox because masonry layout seems more like flex layout than grid to me. If two fully independent browser engines (e.g. Gecko and Webkit, instead of Webkit and Blink) have already usable implementation for display:grid based solution, I'd go with it already because I want this ASAP. That said, I understand the argument that Google is making here and it does seem the best way forward in long run if vendors accept having to write more code for the initial version. And the ability to use `auto` sized tracks with the Google proposal seems like a very nice feature to have.
26:40 I call major bullshit on that. Jen. Simmons has been talking about all of these old layouts used in print media for years now. What she is writing in that article, aligns perfectly with everything she has done so far (watch her Layout Land videos on youtube, they are AMAZING). So I do not believe for a second that Apple is doing this to make the Web harder to contribute to. Webkit is an open source project, anyone wanting to build a browser can go and look at Apple's implementation and learn from it.
I've already voiced my opinion on csswg-drafts issue for this topic. While both syntaxes are similar, I'm way more towards display: masonry (or whatever the name will be). I've teached enough people to know that grid is already complex enough. Having masonry added to this will make it more complex (and I do like my CSS syntax simple). I know, grid is "not that complex" to many of you, but honestly, try to explain nested minmax to some poor intern, who is getting started. Argument about feature parity is not strong enough to me, because if both layouts can share similar things, they will do so in time. But if they can't, (or shouldn't) the bugs, performance issues and discrepancies between browsers will become only worse. I refuse to go back to "if IE then ... else IF Safari then ... else ...". Having safari in back of my head is enough. Having all that said - I just want to get it done already, so that I don't have to write another mega menu, as we had a client recently, who wanted it and I hated the idea of adding masonry lib just for it, so we did it with some heuristics in media queries....
@@futuremapper_ I don't have plan, nor do I hate minmax - I use it pretty much on regular basis. That was just an example from real life that there is some cognitive complexity in current syntax, and that's why I prefer a syntax that is more verbose and targeted, because it would be easier to understand to newcomers and easier to teach.
One downside to this is that it seems like content can be placed somewhat randomly based on the screen size. Of course, it makes sense to reduce the columns and move the content for different devices, but when you think of traditional use cases for masonry content (like newspapers or magazines) you have one fixed layout per page, and people will remember what position the content was on which page. Bringing that masonry to the Web will not allow people to remember where their content was in a large chaotic layout like in many of the examples. While this kind of sucks from a scanability or re-find-ability standpoint, I think this could be really useful for screens with much slower refresh times… Like ePaper displays. On a dedicated reader devices, you eliminate the problem of inconsistent screen sizes (from the individual user standpoint), and you have a much stronger incentive to maximize the content on a single page. This could be a game-changer for browsing web content on ultra-low-power devices that want to prioritize battery life over performance.
The spec should be an abstraction of css grid, but with its own display type of "display: masonry". It can as a default inherit the stuff CSS grid uses, but allow the spec to mature by overriding those properties without having to worry about changing the underlying grid spec. Basically "display: masonry extends css-grid {}" in the OOP world. I don't like the idea of jamming it directly into the grid spec as you'll end up with the 2 specs being tightly coupled, despite their concepts being radically different. Implementation aside, I so would love to be able to use this. Masonry grids are an absolute nightmare to implement currently. Even with libraries like MasonryJS it's just an awful, frustrating experience.
i can't understand why theo makes this sound like imposible. isn't this just a flex with tons of flex-cols? i mean yeah without js is cool but not that hard? was it?
Sure it’s easy when you have a defined set of images you want to display. But what about when you need to add a new image? Or you want to pull a random subset of images from a larger set. You also have the case where you want an image to span across two of the columns. Add in making it work across different devices and screen sizes, complexity starts to increase.
@@danielreynolds9794 screen width / (col size + padding per col) will give you the columns you can fit then you'll just divide the content into amount of columns you have yes this is definitely harder than just a new display type but theo made it sound like the next big thing. still cool tho
I am on the team chrome and google side. To me it makes more sense that grid be a separate from masonry. I mean ask yourself a question, "What is a grid?", and if squares don't come to your mind, then c'mon man what you are even doing on this planet. If masonry becomes part of grid system layout, then you also have to revisit your grid logic, meanwhile if they add it extra, you can keep ignoring to learn as long as you don't need it. Meanwhile if you add it to grid, you never know when and where you will fuck up and then you are forced to learn what this masonry stuff changed within the grid.
Masonry display seems to be the way; too much inherited complexity in the syntax related to grids; and too many edge cases where masonry layout does not behave like grids, so edgy solutions would have to found and they cost time and even more complexity.
Masonry is not a 2d layout, it's a 1d layout just like flex with wrap is but it just wraps differently. Also grid with subgrid already has quite overbloated syntax, why add more complexity on top of that with masonry edge cases? `display: masonry` with common properties like `align-*`, `justify-*` and `gap-*` behaving as expected (just like they do now in both flex and grid) is definitely the way to go. I don't even want to imagine what nightmarish bugs would something like `grid-area: 1 / 1 / -1 / -1` produce in apple's proposed grid masonry.
just use the one you want to use. the only reason that anything is the way it is on the web is because theres so much prior work that changing it would break a bunch of stuff. The fact that these huge companies are arguing about it is literally only to claim authority over the decision making right. Use the one you want and don't support the one you don't want to.
that mostly sucks to look at, there's no way to naturally follow anything, it's just a mess but designers love hard to use things, and often management does too
It's funny to think how easy this is in a desktop GUI kit or game engine vs doing it in web. The best web example I've seen just used WebGL because it ended up being reasonably performant even on mobile.
The problem with WebGL is that you are foregoing almost all the baked in accessibility and sementics that the DOM gives you for free. You are given direct access to the graphics layer to render whatever you want, so ofc its gonna be faster, but at what cost? To replicate all the things the browser gives you out of the box, you need to ship a lot more code to your end-users. All of these reason are also why a lot of people don't like Flutter's Skia rendering and why using it for the web its not that popular.
24:00 I agree with you, overloading synonyms is _bad_ ... And I do think "waterfall" would be better globally because "waterfall" is a much more basic term than the pretty obscure "masonry" (which is in more basic English vocabulary is called "brick wall". Well unless you're referring to the art of laying bricks and cutting stone, i.e. what "masons" do; which this CSS term is _definitely_ not.) and grids already looks somewhat like a brick wall anyway, while "waterfall" clearly implies a vertical flow. In fact, proper actual masonry (with bricks) is very much a horizontal flow where the vertical edges of the bricks never line up, because that would cause weaknesses in the wall; which is what I thought this video was about when I clicked it. I could not understand why we would need a new syntax for this because it's very easy to make a really good imitation of a flemish bond brick wall using only flex or even tables with colspan. (Edit: I just realised that "masonry" in general maybe more refers to shaping of stone than clay brickwork specifically; I'm not 100% sure what a native would think; but since English is my second language, but I'm Norwegian and I've been pretty fluent in English since at least age10; if even I misunderstand the nuanced association of the word, it only proves my point that it's probably not a very good choice internationally with even less fluent speakers.) But I guess "masonry" is better than grid-rows with confusing synonyms of false values.
Actually, come to think about it. This layout is what I _expected_ when I first heard about "grid layout" years ago. Having a rigid grid that is forced to align in both axes at once is simply not how grids are used most of the time in traditional layout and it's what makes grid such a pain to use in my opinion. I propose that they rename the old "display: grid" layout to "display: spreadsheet" or "display: annoying-rigid-grid" or something and call this new more sensible layout "display: grid". 😁Which of course would not work because of backwards compatibility... So maybe call this new layout "display: usable-grid" ?
The order of the Masonry really isn't that hard to understand, even in the examples you mentioned it on: The columns went downward, so each element gets placed in the highest place it can, and that determines the order. Just look at the top where each element starts as you count, you will go left and right, but you will never go back up.
Building apps in browser technology: Here are the 20 valid ways to center a div. Building apps in a competent desktop GUI: Here is the one correct way to center a panel within a panel.
Imho this debate isn't about what designers want, but what maintenance hell the developers want. Either code/spec duplication (Google) or more corner cases, weird bugs and browser incompatibility (Apple). Considering how buggy grid implementations are (afaik), I think Google's position is the more sane approach.
Make everyone unhappy and add masonry to display: flex
display: flex-masonry
@@JulianKingman no no.
Display: flex
Flex-wrap: masonry
This but unironically
@@untlsn honestly there is an argument to be made for this
@@untlsn :D
"how to center a div using masonry layout"
New stress unlock.
Put it in another div
And ask the questions: how to center a div with flex box ?
you're doomed
don't
I'll like to cluster my divs in a circular pattern outward from the center
Masonry mega menu is one of those things that the customer wants and you always have to do quite the math to try and figure out what goes where to temporary arrays in arrays and then recalculate that on window resize when it gets below or above certain thresholds. I’m glad this might come soon natively
why can’t you just do column-count/column-width? am I missing something? mega menu doesn’t seem like it needs masonry to solve
you only have to do it once anyways
Oh no, text rectangle calculations with fonts taken into account. It's always a nightmare. It's always a nightmare.
Masonry deserves its own display type for sure. Developers should be able to have some comfort knowing they've conquered block, flex, grid and masonry separately. I remember the hell that existed when browsers did not agree, and I don't want to return to that by convoluting grid further.
The other problem with "off" is it fails the "least surprise" test. Turning something off you don't expect to unlock a whole new layout type with a bunch of custom options
I follow their logic, but ultimately that's a horrible place to land.
it should be something more explicit like no-rows
@@victornpb this is a good idea! make sure you make your voice heard on the mailing list or whatever
I feel like a lot of commenters are either not understanding how things are ordered in a masonry layout or just going with various variations of "but why don't you just solve it using a lot of complicated CSS+JS work instead!"
Like… Noone's forcing you to use it, and the same could be said for Grid. Why would any of us want to make layout with anything but tables and FRAMESET? One of the best things with modern CSS is that it conforms to the kind of layouts people actually want to do. We don't have to do float:left and margin:left anymore, or margin: 0 auto for centering. Making completely normal layouts doesn't feel like solving a rubik's cube. And it shouldn't.
Job security joined the chat
@@GerrodNoordsylovesu You'd think anyone who's been around webdev for more than a few minutes would know by now there is no job security =) Or, if there is, it can only be achieved by being ready to throw out everything every few years or so and learn everything from scratch. =)
Easy to explain: Masonry layouts are often used for endless-scrolling-pages, which means lots and lots of items. More items = more work a JS solution has to do = endless-scrolling-pages grow significantly slower the further you scroll down. Make it built-into the browser, and it will be much faster. Everybody wants that!
Yeah, I mean as an old school web dev, I can say that there is pretty much nothing in modern CSS that you couldn't do 20 years ago with CSS+JS, it was just a major pain in the ass and a minefield of browser compatibility.
While I do find a lot of newer css features somewhat superfluous, I appreciate greatly that now you can sometimes do in a few lines of CSS what used to take sometimes hundreds of lines of difficult to debug javascript.
Both Jen Simmons and Rachel Andrews are such legendary figures in CSS. I have been a FE developer for 15 years and I learned a lot from their articles and videos, that this feels like I'm watching my aunts fight.
The unintuitive order seemed intuitive to me: you're trying to even out the heights of each column, which this does by always adding the next item into whichever column is currently the shortest. I don't feel like it's appropriate for something like the footer menu example since a user is more likely to expect newspaper column order and expect the submenus to maintain that order across devices, but it works well for things like galleries of non-sequential images.
I was thinking the same. A way to order by "top to bottom" or by "column" would be nice.
7:46 It isn't unintuitive, it just tries to fill up the shortest row, which is exactly what masonry is.
Having said that, masonry has to be its own display type. If the concern is that the features grid has are also useful for masonry and visa versa... just implement them for both. The people responsible for the spec should just adjust both when that makes sense.
The fact that Apple claims most of its demos wouldn't be possible with alternative proposals, while Google has to point out that all demos very much would still be possible also just seems scummy behavior and an attempt at FUD from Apple's side.
You also have another issue. Standard shift. People will likely request more features to Masonry, and some might actually be incompatible with Grid, so you end up having bloat in the design specifications, and some really annoying "Oh, but that works here, but not here, but it's the same thing!" kind of behaviour, which we see everywhere in CSS already.
I mean, you already have keys that doesn't work unless you are Masonry in the first place, so why should Grid have added to it?
The problem with doing it as part of CSS Grid is that the whole spec assumes it's styling a _modular_ grid, so a bunch of the rule work in ways that only make sense for modular grids - grid-template-rows is a great example of this: the way the rule works when you set it to "none" is not to have no rows, but to have no _explicit_ rows (meaning you still have rows). Unless the _entire_ CSS Grid spec is going to be changed to accommodate the fact that grids can now be columnar, it makes no sense to have masonry as part of that spec.
7:44 It's not unintuitive what goes where, it's simply top to bottom. And if some elements end up at the same y, it's left to right.
I did masonry layout recently and it was pretty easy with one trick - just set layout to grid and set item's `grid-row: span` to item's height (in whatever unit,). It doesn't cover all cases but that's basically it
That works only if the columns are the same size, though, right? It won't work if you need to have height dependent on the width and varying widths.
I legit didn't know I needed this until I saw the mega menu example and realized oh my goodness, I just did that manually last month for one of my projects.
For the "weird" order of images in masonry, that's actually exactly how I want it to behave. On my photography portfolio website I don't really care where every picture is horizontally, I just want control over the vertical order.
24:00 I agree 100%! I think "off" shouldn't even be a keyword for the exact reason you explain here.
I initially thought the Pinterest-like image layout was too niche for adding it to CSS, but I have to admit seeing all the use cases (mega menu, etc.) makes it super appealing
One obvious overlooked application are any type of page with many options/fields contained in arbitrarily long sections: Option/settings pages, Dashboards, CRM, ERP, CMS, ... Current layouts will waste a lot of space for such applications. With masonry we can efficiently use all of the space on desktop, and degrade gracefully to single column on mobile, all while retaining a somewhat intuitive order for the individual elements while resizing.
regarding the order of photos in masonry (see around 7:35), I believe the "traditional" idea here is that they are ordered by their offset from the top... so once elements have filled the width along the top, the next element will try the next highest available "column", resulting is 6 being below 3, 7 below 4, 8 below 6, each time because the selected spot is closest to the top of the view.
More flex-y than grid, but more grid-y than flex. I can understand the want to not build on the tech-debt of Grid's existing implementation complexity, I also think "subgrid" doesn't have a place in Masonry. It'd be good to be able to re-use as much syntax and phrasing as possible, I share the dissent for "off".
What if Masonry (eventual name can be discussed, though "Waterfall" suggests only downward, so not fitting imo) used "*-template-columns/rows" and "*-direction" and we generalised some terminology like we have done in the past?
Sure "waterfall" suggests something going downwards... But wouldn't that be the direction for this type of layout 99% of the time?
Because horizontal scrolling is fairly rare, and generally requires you to mentally rotate and flip everything from the normal behaviour anyway, so I think we'd be able to handle "horizontal waterfalls" in those rare cases.
I quite like the term "waterfall" because it suggests the direction of flow, from top to bottom in parallell, while masonry doesn't imply flow at all; but rather implies something very rigid and static with usually bricks that are stacked so that vertical gaps are _not_ aligned. If anything masonry implies something being build from the ground _up_ in horizontal layers rather than from the top down. (And in fact when I clicked this video; I was imagining a table full of cells with colspan of 2 and I could not understand how that was anything new.) Also "waterfall" is a much more elementary word than "masonry" so it's much more likely that second language speakers have heard the word "waterfall" than "masonry". And it's already a common term in many countries for this kind of layout.
this has been sitting behind a flag in firefox for the past 4 years, good on chromium for finally catching up
If flexbox is grid or grid is flexbox, then masonry is grid. Flexbox, grid, and masonry are all very similar and related, but fundamentally different imo. Whatever makes it simplest and most intuitive for people learning and writing CSS imo.
The layout algorithm positions items from left to right, placing each one at the highest available spot. Initially, the first X items are placed at height 0, so they line up horizontally. If, for example, the second item has the shortest height, the next item (N+1) will be positioned directly underneath it, creating a balanced flow.
I think I agree with ur final statement: im leaning towards the "display: masonry" method, but would be fine either way as long as it just gets there :P
48:16 Google approach vs the Apple approach
Mozilla:👁👄👁
Mozilla:
30:48 About that, it seems like what we saw Apple did (when we saw the numbers) involved going left to right at equal y positions, and going for the first fit otherwise. Each time, the topmost slot was the one that was filled, so that was likely done in a single loop. Of course, we start to see more complex algorithms when images span over several columns, but even then, it wouldn't imply processing every possible layout. In the first place, once the width of the image is known, the height is also known using its aspect ratio. That means no "trying every possible way to get measurements", it's not an n² problem, more likely to be some sort of n log n.
7:20 - The "one weird thing" about how the browser is doing it is probably by placing N columns and looping over them sequentially, each time keeping track which column is the smallest height and placing the image there, then repeating the loop for each image you need to place. You can notice #1 to #6 are the top ones, #7 is placed right after the shortest image and then #8 is placed after the second shortest one. Then the shortest column for #9 turns to be the one starting with #4 and on and on...
(at least that's what I think and how I would have done it - I don't even wanna know the pain of optimally re-rendering it on window resize.)
I think one additional benefit of masonry over grids is that it becomes more accessible, each item having a dynamic size makes it easier to remember where on the page a piece of information was, as opposed to everything being a samey height and width.
I haven't done one before, but I think the menu thing is easy enough to do with normal flex layouts by transposing the content order. The case for the endless scroll masonry thing is the use case that is harder to emulate, because with an undefined amount of content you can't precompute the transpose.
The algorithm for selecting the next placement spot appears to be you place the next image on the shortest column. A few years ago I wrote an algorithm for placing images in a way that balances the left to right top to bottom griddy ordering with even column sizes. I wonder if they would accept algorithm suggestions
This is basically a more efficient way of doing the "gallery dense" CSS styling. And has a bit more styling options like removing all blank space, but still, this is layout is achievable so I don't understand the emphasis on how hard/impossible this is right now, because it's not: note, went and read webkits blog and I see the use case this is intended for more than just images. Their reasoning is solid for display: grid and have put far more effort and thought into their blog and argument to support it than Chrome has with theirs. I very much support including it to the grid layout.
Another possible example/use case for this would be creating comic and manga page layouts for the cells/panels.
Amazing. We need this 10 years ago.
The menus are nice and definitely a valid use case for masonry, but in my opinion, they've been pretty simple before with flexbox. All you'd really need to do in your media queries is change the order.
Perhaps I'm just not understanding though. It's admittedly been a while since I've had to make a menu like this.
I think adding it to grid adds complexity, which gives the biggest argument of all: how easy is this to teach to jr devs? display:masonry gets my vote because explaining display grid was already a time sink.
The best alternative to masonry I've seen is the 'break the grid' solution: you first align items on a grid, and then you systematically offset them with negative margins. This sucks because it requires the use of magic numbers or js to calculate the negative margins.
If masonry === "break the grid", then it feels both weird (why 'break the grid' if we don't want it in the first place?) and not weird (grid as 'baseline' for 'broken grid' behavior) to make masonry part of grid... I'm not sure which camp I lie on, though I like the "grid as 'baseline' semantics of masonry" idea.
I never really thought about how much of a hack media queries are. The less I need to use them, the better I feel.
Amazing it's taken this long tbh.
gotta say I'm leaning towards separate. just the fact that you're not cluttering and convoluting the already messy grid stuff means its also definitely more easily extensible for updates
okay, this would be amazing feature.
i like google appaorch and breaking this out to be it's own.
display: masonry makes ways more sense to me. I'd say that the difference between grid and masonry is similar as between flex and grid. Both flex and grid naturally order elements as a wrapping row, but grid has added logic for enforcing specific horizontal spacing (i.e. columns). Masonry is similar to grid in this regard, but it's different from both flex and grid in how it places elements in the columns - instead of putting elements in consecutive columns, it prefers to skip the columns if it levels the bottom better. If another ordering gets available (e.g. column by column, better for this menu case) it still will be something that is kinda similar to both grid and flex, but close to neither.
My question is, what are developers switching between the most? Are they going to start with flexbox and then want masonry? Or start with a grid and want masonry? Everything is an abstraction at the end of the day, so deciding what things are really about is based on the job to be done, and determining the boundaries of the job to be done is usually best done by looking at what people see as substitutes.
I've used CSS `columns` (not grid... It's a less known property) for menus before. I didn't think we need masonry for that.
right. In modern browsers there even are means dealing with the wrapping content issue.
We're practicing masonary with this one.
Google really struggled to implement subgrid in a timely fashion so they might be worried about history repeating itself there. As someone who mostly works on technical webinterfaces and not user-facing websites I do have a major use case for subgrid (a concept I call soft nesting) but not for masonry.
Edit: After seeing their side of things, honestly I'm with google on this one. Masonry should either be a seperate layout or an extension of flexbox. Implementation wise, masonry has little in common with grid.
I made a masonry layout with some basic CSS and like 8 lines of JS for a reddit gallery front end i was working on. While it was a pain in the ass and its not perfect. Im excited to see this be implemented in too the CSS standards.
I'm on the other side of the fence. I usually side with google when it's about web standards, but I prefer apple's approach so much. Especially when it comes to feature partiy. Subgrids in a masonry layout would be so dope.
Honestly, if I had to pick one Google version is a win.
But I'd choose not to have this on the css spec. I've used and depended on masonry a few times but i feel it's very niche. Different from flex and grid, that i was using even before all browsers actually behaved well with them.
I just want this: `grid-template-rows: repeat(3, 1fr) masonry 2fr;`
If this is done with a nested subgrid that can be display masonry, I’m fine with either option.
```
display: masonry;
grid-template-columns: subgrid;
```
I definitely went into this thinking it should be a separate display type exactly for the reason Apple highlighted, it doesn't align in both dimensions. But their examples prove to me that the benefits of adding to grid are huge, and that they are also compatible concepts. Making it a separate concept would only be a downgrade in functionality, most especially in the future, I don't think restricting the feature to not allowing mixing fixed and intrinsic layouts is a good idea since that's doesn't even really represent the majority of waterfall implementations already on the web.
In terms of complexity for web developers, it looks like it's easy enough to just use a demo website to figure out a layout you want, copy paste the CSS, and tweak from there. People already do this for current CSS grid and flexbox, and lots of other CSS.
I don't really buy a lot of Google's implementation or performance complexity complaints. Firefox and Safari already implemented it no problem.
Why would it have to be a downgrade? Those features can be implemented into Masonry, as a `display: type`
@@SioxerNikita and double the spec?
@@futuremapper_ And making sure the spec has sections that directly relates to what you need, instead of half the keys being unusable due to using a specific feature in the display type.
It will look unintuitive to see which goes where but I think it's because they are counting in terms of left to right and then closest from top then down to bottom
2:50 but it's doable with CSS. You just have a small enough grid and you decide over how many squares each image will sretch. No javascript required. You can have individual images break out into multiple rows and multiple columns around them and you can have the next images not doing that and instead following equal amount of columns and rows.
But is it dynamic across different resolutions ? That is, can you define it to look good on all resolutions without using multiple definitions (aka using media queries) ?
@@Winnetou17 I remember seeing a video about dynamic masonry grid. Can't tell off the top of my head.
point is you won't have to jump though hoops to make something like that, it's just instant profit
firefox does btw. already support "masonry". In testing versions it's enabled by default and in stable there's a feature flag to enable it
Chromium is the only platform that DOESN'T support it
I feel like you should be able to specify the preferred fill direction, so whether it's based on rows or columns
grid-template-columns: only
grid-template-rows: implicit
Choose one of these.
display: pack; pack-direction: row; pack-size: repeat(auto-fill, minmax(200px, 1fr) ); pack-gap: 1rem, 3rem;
Masonry layout, keeping good developers on the level 😉
To avoid confusion, we should just call it display: flex-grid;
Simple, descriptive, I can't foresee any issues.
Really though, at first I was really into having it as a part of grid, but over the course of the video it's clear a new display type makes a lot more sense. It really will be a 2d flex more than a grid.
Definitely don't like 'masonry' as the name though. I guess it makes sense, but it's not immediately obvious. Not sold on waterfall either. Naming things is hard.
I was about to ask mid way through, what does w3 group say about all this? As usual, "why not both at the same time, and let them figure it out". I swear, they're so Switzerland and I'm almost thankful for it. I'm team display:masonry personally. It's easier to mirror grid code where needed, than it is to fix defunct conflicts between two similar standards.
The menu thing for the footer, would be awesome to have.
I think masonry should be optional feature of either display:grid or display:flex. I would personally prefer flexbox because masonry layout seems more like flex layout than grid to me.
If two fully independent browser engines (e.g. Gecko and Webkit, instead of Webkit and Blink) have already usable implementation for display:grid based solution, I'd go with it already because I want this ASAP.
That said, I understand the argument that Google is making here and it does seem the best way forward in long run if vendors accept having to write more code for the initial version. And the ability to use `auto` sized tracks with the Google proposal seems like a very nice feature to have.
26:40 I call major bullshit on that. Jen. Simmons has been talking about all of these old layouts used in print media for years now. What she is writing in that article, aligns perfectly with everything she has done so far (watch her Layout Land videos on youtube, they are AMAZING). So I do not believe for a second that Apple is doing this to make the Web harder to contribute to. Webkit is an open source project, anyone wanting to build a browser can go and look at Apple's implementation and learn from it.
It's also blocked by the tabindex order. It's not very usable if tabindex visual is not released. Css working group will roll that one out first.
I've already voiced my opinion on csswg-drafts issue for this topic. While both syntaxes are similar, I'm way more towards display: masonry (or whatever the name will be). I've teached enough people to know that grid is already complex enough. Having masonry added to this will make it more complex (and I do like my CSS syntax simple). I know, grid is "not that complex" to many of you, but honestly, try to explain nested minmax to some poor intern, who is getting started. Argument about feature parity is not strong enough to me, because if both layouts can share similar things, they will do so in time. But if they can't, (or shouldn't) the bugs, performance issues and discrepancies between browsers will become only worse. I refuse to go back to "if IE then ... else IF Safari then ... else ...". Having safari in back of my head is enough. Having all that said - I just want to get it done already, so that I don't have to write another mega menu, as we had a client recently, who wanted it and I hated the idea of adding masonry lib just for it, so we did it with some heuristics in media queries....
So whats your plan to replace minmax then?
@@futuremapper_ I don't have plan, nor do I hate minmax - I use it pretty much on regular basis. That was just an example from real life that there is some cognitive complexity in current syntax, and that's why I prefer a syntax that is more verbose and targeted, because it would be easier to understand to newcomers and easier to teach.
I read about this coming soon like 4 years ago, how has this not been a thing yet
One downside to this is that it seems like content can be placed somewhat randomly based on the screen size.
Of course, it makes sense to reduce the columns and move the content for different devices, but when you think of traditional use cases for masonry content (like newspapers or magazines) you have one fixed layout per page, and people will remember what position the content was on which page.
Bringing that masonry to the Web will not allow people to remember where their content was in a large chaotic layout like in many of the examples.
While this kind of sucks from a scanability or re-find-ability standpoint, I think this could be really useful for screens with much slower refresh times… Like ePaper displays.
On a dedicated reader devices, you eliminate the problem of inconsistent screen sizes (from the individual user standpoint), and you have a much stronger incentive to maximize the content on a single page.
This could be a game-changer for browsing web content on ultra-low-power devices that want to prioritize battery life over performance.
1:05 Completely unrelated, but, I love that shirt
The spec should be an abstraction of css grid, but with its own display type of "display: masonry". It can as a default inherit the stuff CSS grid uses, but allow the spec to mature by overriding those properties without having to worry about changing the underlying grid spec. Basically "display: masonry extends css-grid {}" in the OOP world.
I don't like the idea of jamming it directly into the grid spec as you'll end up with the 2 specs being tightly coupled, despite their concepts being radically different.
Implementation aside, I so would love to be able to use this. Masonry grids are an absolute nightmare to implement currently. Even with libraries like MasonryJS it's just an awful, frustrating experience.
This would be perfect for the site I am working on now.
oh they're finally shipping masonry? didnt they start talking about this 5+ years ago?
Oh I would love this! I have tried to do Masonry using pure CSS, but it's so clunky and only half works
I don't even do front end development anymore, but the Google approach seems more intuitive to me.
I have to build something like that now, which some element have double width and/or double height.
Would love to know what is expected to happen with both applied:
grid-template-rows: masonry;
grid-template-columns: masonry;
i can't understand why theo makes this sound like imposible. isn't this just a flex with tons of flex-cols?
i mean yeah without js is cool but not that hard? was it?
Sure it’s easy when you have a defined set of images you want to display. But what about when you need to add a new image? Or you want to pull a random subset of images from a larger set.
You also have the case where you want an image to span across two of the columns.
Add in making it work across different devices and screen sizes, complexity starts to increase.
@@danielreynolds9794 screen width / (col size + padding per col) will give you the columns you can fit then you'll just divide the content into amount of columns you have
yes this is definitely harder than just a new display type but theo made it sound like the next big thing. still cool tho
My body is ready
At least for React, there are good packages for this already. That would be quite the task without them. Hope it does get browser support for all
For me the simple question is: Are comic books not drawn in a grid? They sure are most often in masonry layout!
I am on the team chrome and google side. To me it makes more sense that grid be a separate from masonry. I mean ask yourself a question, "What is a grid?", and if squares don't come to your mind, then c'mon man what you are even doing on this planet. If masonry becomes part of grid system layout, then you also have to revisit your grid logic, meanwhile if they add it extra, you can keep ignoring to learn as long as you don't need it. Meanwhile if you add it to grid, you never know when and where you will fuck up and then you are forced to learn what this masonry stuff changed within the grid.
Masonry display seems to be the way; too much inherited complexity in the syntax related to grids; and too many edge cases where masonry layout does not behave like grids, so edgy solutions would have to found and they cost time and even more complexity.
grids tend to be column designed while masonry is always rows as in building a wall.
I haven't been this excited about CSS since Myspace.
Masonry is not a 2d layout, it's a 1d layout just like flex with wrap is but it just wraps differently. Also grid with subgrid already has quite overbloated syntax, why add more complexity on top of that with masonry edge cases? `display: masonry` with common properties like `align-*`, `justify-*` and `gap-*` behaving as expected (just like they do now in both flex and grid) is definitely the way to go. I don't even want to imagine what nightmarish bugs would something like `grid-area: 1 / 1 / -1 / -1` produce in apple's proposed grid masonry.
Is it bad that my primary concern is the Tailwind implementation? 😅
just use the one you want to use. the only reason that anything is the way it is on the web is because theres so much prior work that changing it would break a bunch of stuff. The fact that these huge companies are arguing about it is literally only to claim authority over the decision making right. Use the one you want and don't support the one you don't want to.
that mostly sucks to look at, there's no way to naturally follow anything, it's just a mess
but designers love hard to use things, and often management does too
Oh, it's that thing I did in Flutter a while ago.
Please add masonry AND waterfall. They look similar, but have different orientations. Thus the are siblings not the same.
It's funny to think how easy this is in a desktop GUI kit or game engine vs doing it in web. The best web example I've seen just used WebGL because it ended up being reasonably performant even on mobile.
The problem with WebGL is that you are foregoing almost all the baked in accessibility and sementics that the DOM gives you for free. You are given direct access to the graphics layer to render whatever you want, so ofc its gonna be faster, but at what cost? To replicate all the things the browser gives you out of the box, you need to ship a lot more code to your end-users.
All of these reason are also why a lot of people don't like Flutter's Skia rendering and why using it for the web its not that popular.
the quotes template areas should have been written and read on separate rows, just like 'normal' template-areas.
I saw this I believe earlier this year and was mad that only safari had it in preview 😭
This is masonry if you tilt your head 90 degrees. Brick are laid in rows.
24:00 I agree with you, overloading synonyms is _bad_ ... And I do think "waterfall" would be better globally because "waterfall" is a much more basic term than the pretty obscure "masonry" (which is in more basic English vocabulary is called "brick wall". Well unless you're referring to the art of laying bricks and cutting stone, i.e. what "masons" do; which this CSS term is _definitely_ not.) and grids already looks somewhat like a brick wall anyway, while "waterfall" clearly implies a vertical flow.
In fact, proper actual masonry (with bricks) is very much a horizontal flow where the vertical edges of the bricks never line up, because that would cause weaknesses in the wall; which is what I thought this video was about when I clicked it. I could not understand why we would need a new syntax for this because it's very easy to make a really good imitation of a flemish bond brick wall using only flex or even tables with colspan. (Edit: I just realised that "masonry" in general maybe more refers to shaping of stone than clay brickwork specifically; I'm not 100% sure what a native would think; but since English is my second language, but I'm Norwegian and I've been pretty fluent in English since at least age10; if even I misunderstand the nuanced association of the word, it only proves my point that it's probably not a very good choice internationally with even less fluent speakers.)
But I guess "masonry" is better than grid-rows with confusing synonyms of false values.
Actually, come to think about it. This layout is what I _expected_ when I first heard about "grid layout" years ago. Having a rigid grid that is forced to align in both axes at once is simply not how grids are used most of the time in traditional layout and it's what makes grid such a pain to use in my opinion.
I propose that they rename the old "display: grid" layout to "display: spreadsheet" or "display: annoying-rigid-grid" or something and call this new more sensible layout "display: grid". 😁Which of course would not work because of backwards compatibility... So maybe call this new layout "display: usable-grid" ?
The order of the Masonry really isn't that hard to understand, even in the examples you mentioned it on: The columns went downward, so each element gets placed in the highest place it can, and that determines the order. Just look at the top where each element starts as you count, you will go left and right, but you will never go back up.
Building apps in browser technology: Here are the 20 valid ways to center a div.
Building apps in a competent desktop GUI: Here is the one correct way to center a panel within a panel.
I’m much more interested in discussing the upcoming position: missionary proposal.
What if I want to use a column subgrid and masonry rows? Not sure if display type covered that usecase.
Imho this debate isn't about what designers want, but what maintenance hell the developers want. Either code/spec duplication (Google) or more corner cases, weird bugs and browser incompatibility (Apple).
Considering how buggy grid implementations are (afaik), I think Google's position is the more sane approach.
thanks theo for this video
masonry is great for bento
I can't believe I'm saying that, but with a cursory examination, I agree with Apple.