This awesome CSS feature is blocked by drama (Google and Apple can't agree)
HTML-код
- Опубликовано: 10 окт 2024
- Man I really hope masonry ships. I think I'm team display: masonry rather than grid, but I could be convinced either way. JUST GIVE IT TO ME.
Thank you to ahrefs.com/ for sponsoring this video. Genuinely got hooked on their RUclips channel and I recommend y'all check it out too
SOURCES
webkit.org/blo...
developer.chro...
www.w3.org/blo...
developer.chro...
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
![Vue.js Course for Beginners [2021 Tutorial]](http://i.ytimg.com/vi/FXpIoQ_rT_c/mqdefault.jpg)
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
"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
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
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. =)
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 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
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.
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.
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.
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
lun dev has another trick, all the images have `w-full` and `h-auto`, but the parent that contains them has `columns-[300px]`(or whatever) and it works remarkably well
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.
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.
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.
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
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....
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
Amazing it's taken this long tbh.
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 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.
As someone who’s bounced between FE & BE a lot and has had to re-learn CSS multiple times, my initial reaction was to not care. CSS is already hard, and adding (admittedly very cool) new functionality would understandably make it harder, so “how” CSS became harder didn’t really strike me as particularly important.
But the more I thought about it, the more I realized that the way I learn CSS is very concept-oriented - I go one concept at a time, as-needed. There are a few concepts I’ve never bothered to (re-)learn because they’re either too complex or confusing. My big never-learned CSS concept (other than float) is Grid, primarily because it’s too dense and confusing for me to wrap my head around when flex covers the majority of use-cases I care about.
The fact Theo, by admitting to still be bad at Grid relative to Flex, seems to feel similarly despite being far more experienced FE person than me, makes it feel like making masonry part of Grid is essentially gate-keeping. Grid is already arguably too hard to learn, I hope it doesn’t get harder.
As a side note: Arguing about whether masonry is a “type” of grid strikes me as a complete waste of time. It’s 99% semantic, and in my experience “semantics-oriented” APIs are almost always worse to actually use than “functionality-oriented” ones. Forcing users to contort their brains in unnatural ways to use a thing for little other reason than “word means word” is just bad API design IMO.
Amazing. We need this 10 years ago.
We're practicing masonary with this one.
this has been sitting behind a flag in firefox for the past 4 years, good on chromium for finally catching up
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?
okay, this would be amazing feature.
i like google appaorch and breaking this out to be it's own.
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'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.
Masonry layout, keeping good developers on the level 😉
Another possible example/use case for this would be creating comic and manga page layouts for the cells/panels.
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.
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.
I read about this coming soon like 4 years ago, how has this not been a thing yet
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.
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 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.
The menu thing for the footer, would be awesome to have.
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.
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'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.
This would be perfect for the site I am working on now.
I haven't been this excited about CSS since Myspace.
I feel like you should be able to specify the preferred fill direction, so whether it's based on rows or columns
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.
oh they're finally shipping masonry? didnt they start talking about this 5+ years ago?
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
Oh, it's that thing I did in Flutter a while ago.
I never really thought about how much of a hack media queries are. The less I need to use them, the better I feel.
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.
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
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;
```
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.
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.
display: pack; pack-direction: row; pack-size: repeat(auto-fill, minmax(200px, 1fr) ); pack-gap: 1rem, 3rem;
My body is ready
I have to build something like that now, which some element have double width and/or double height.
I don't even do front end development anymore, but the Google approach seems more intuitive to me.
I saw this I believe earlier this year and was mad that only safari had it in preview 😭
Would love to know what is expected to happen with both applied:
grid-template-rows: masonry;
grid-template-columns: masonry;
grid-template-columns: only
grid-template-rows: implicit
Choose one of these.
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
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.
"grid-template-rows:"... none and off are not synonyms. You don't turn your lights none or answer how many siblings you have with "off". One is a count and the other means disabled.
Overall, I have to go with Googles
display: masonry.
Feels like it'll be easier to live with, long term and i do like the better performance.
Is it bad that my primary concern is the Tailwind implementation? 😅
thanks theo for this video
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.
I will actually learn SEO now
I’m much more interested in discussing the upcoming position: missionary proposal.
If having one property of grid makes other properties of grid not work, that's confusing for devs. That's a great reason for masonry to be its own display.
masonry is great for bento
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.
As a designer, I vote for display grid. If devs wants to pull out masonry/waterfall from grid because of dev reasons, that’s fine. I don’t think devs have to be using same terminology as designers.
the quotes template areas should have been written and read on separate rows, just like 'normal' template-areas.
Browser devs fighting about shit like this when they could just work on adding native CSS mixins
I can't believe I'm saying that, but with a cursory examination, I agree with Apple.
grids tend to be column designed while masonry is always rows as in building a wall.
6:05 This describes Apple SO _fucking_ perfectly
I mean, this was definintely a user error, but this flip-flopping between "omg that's actually really neat" and "jesus christ how can you mess that up" is very real
Pinterest clones coming in
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
Masonry is a good grid to have, but the proposed implementation is too specific and opinionated. Instead of adding more and more "predefined" layouts, CSS should offer more general tools for developers to define their own layout logic. We need more things like `calc` and less things that are basically predefined layout templates/constrain solvers. I wrote a longer comment on the GitHub issue for anyone who wants to chime in.
Did you try columns CSS property?
Why have I seen this video have like 4 titles before I watched it
A/B testing
columns: 300px; done hehe
As soon as the apple devs started saying things weren't going to be possible in the chrome implementation I got very suss and was pretty sure I'd end up siding with chrome and i was right. I couldn't imagine a world where chrome would say yea thats impossible with our way but lets do it anyway. And when you have to manipulate the counterpoint its usually because your point aint that great.
radical
I'd rather have a new display type of masonry. It's so easy to understand.
grid should not be made any more complicated. separating masonry can be better.
separate? it's literally a grid structure
Kind of weird to initially assume Apple is roght from their blog post. They had very weak arguments
Theo loves drama. Without drama this channel would die.
Of course, it's a commentary channel not a tutorial channel.
Isn't this that layout that doesn't need flex or grid at all?
Adam Wathan should just decide
9:15 you can just do break-inside: avoid???
@t3dotgg This mega menu is possible with list, right now plain css.
I am not too interested in this, as I genuinely _despise_ masonry. But if _this_ is what HomeAssistant needs to have a non-garbage user interface, then I'll wholeheartedly support it
8:33 Same. That actually makes sense now, huh
Is the masonry free?
6:12 Man, how the atmosphere changed in couple of seconds for apple XD
25:10 He's probably wrong because he used "there's" with a plural.
does css have type safety?
title: I can't wait for this to ship
length: 48:24