Eric Meyer: Hello there. I'm Eric Meyer and I'm a developer advocate at Igalia.
Brian Kardell: And I am Brian Kardell. I'm also a developer advocate at Igalia.
Rachel Andrew: Hi, I'm Rachel Andrew. I work for Chrome at Google and I lead developer content there. That's primarily publishing to web.dev and developer.chrome.com.
Eric Meyer: We asked Rachel on today because there's a thing happening in CSS. There's a lot of things happening in CSS, but the thing we want to talk about today is masonry layout. We have Flexbox layout and we have grid layout, and we have other forms of layout that we don't use anymore for the most part. Masonry is kind of the Pinterest layout thing, or if you're of a somewhat older bent, the Flickr layout approach where you have tracks of content that slot together. This has been, I mean, it's a relatively common layout pattern, but CSS doesn't have super convenient ways to do it so far. Rachel, what did I get wrong about my description of masonry?
Rachel Andrew: I think it's really hard to describe layout on a podcast. End up sort of gesticulating with my hands. Yeah. I think masonry is an interesting one because it's kind of a mixture of layout methods. The closest you can really get to it at the moment is with multi-col. If you have a bunch of say images and you use multi-col to lay them out, you'll get something that looks like a masonry layout, which you don't have strict rows. You have things that sort of fall into columns and then they're not lined up in rows across. The problem with that is the content order goes down the column, and actually what people want with masonry is they want to go across the row typically in terms of the order of stuff. And so that's really what people are asking for is this kind of tightly packed layout that doesn't have strict rows. If you try and do that with grid, you end up with gaps because if you have your sort of first row, you have your tallest item in there, that's going to define the height of the rows, you're going to end up with the space underneath things next to it. Yeah. Masonry has this kind of nice tightly packed layout where it kind of doesn't matter how tall the things are, for example, because they're going to rise up next to each other. It's almost like a sort of 2D flex layout I guess. But it's not like a strict grid when you look at it. It's a set of columns with stuff in. And yes, describing these things on a podcast isn't easy.
Brian Kardell: The thing I like about what both of you said is that you're trying to describe masonry, and it's also to some extent masonry as you understand it, but it's a metaphor, it's an abstraction, and there are slightly different variants of what people have done and called masonry. The name came from comparing it to walls made of blocks where they're kind of uneven. But that seems like actually a poor analogy because you would not really have a mortar joint that travels completely directly vertically on a wall probably. And if you think about bricks are also masonry, if you were describing bricks, I have wall outside my house that's made of literal stones and they have lines that go across horizontally. I don't know, it's interesting because I think we're struggling for a name and we're dealing with past names that people have come up with, and there was no standard that somebody wrote down that said, this is what masonry means. And so people have interpreted differently. This is the thing that happens all the time in standards, right? Now we get to a point where we do want to write it down, we do want to standardize and make it easy, but it's like, first we have to agree on what is the it, and then second it's going to potentially involve how much is the it like other things and how much does that matter both technically in the sense of things that we already have like grid or do we call it masonry or does that not work conceptually because of how we're defining it or because of maybe language barriers? Maybe that's a very Anglo centric kind of term or something. Or also other terms are also used like waterfall, and I can see the visual metaphor there, but also maybe that's loaded. It's an interesting question when you talk about naming always. Famously one of the hard problems.
Rachel Andrew: Yeah. Yes, definitely. And sort of interestingly, we have our content on developers.chrome.com machine translated into a whole bunch of languages, and we actually started to get, after that post went up, we got people who speak English and another language telling us how badly the machine translation was translating masonry. That's kind of interesting. And we get this all sorts of things obviously because machine translation tends to try and very literally translate things which results in all kinds of hilarious things, but that was interesting. It doesn't really translate that well to whatever it ends up as. And I think that's definitely a thing with naming things is how does that work around the world and how does that work when it's in another language?
Eric Meyer: Yeah. And I imagine if we were to change it, let's say from masonry to waterfall, that probably wouldn't help any in that way.
Rachel Andrew: Yeah. I mean there's never a perfect answer to this, but I think naming is a good place to be going out and getting developer feedback because especially if we can get out to a more diverse range of people and people who speak different languages because then hopefully we can pick up where names just seem really odd to someone that might not to those of us who only speak English and are used to the way that technical things are named.
Brian Kardell: Didn't we try to give this a name, Eric, where if you poll people on the internet, you wind up with somewhere around 50/50 on everything?
Eric Meyer: I call it Kardell's law of internet polls.
Brian Kardell: Right.
Rachel Andrew: Yeah.
Eric Meyer: Which states more or less that almost any poll you put online will end up 50/50.
Rachel Andrew: Yeah. I'm not convinced that voting on these things is great. I think putting it out there and saying, hey, does anyone have any feedback on this? Does anyone have any thoughts? Does this make sense in terms of how you see this?
Brian Kardell: Yeah.
Rachel Andrew: Yeah, to pick up the really poor choices that we might not notice culturally. Sometimes words have meanings that you just don't know. And so I say even between Brits and Americans, there can be things that are very different. And so I think that putting names out that is actually quite useful, not so much for we're going to use the one that most people vote for because these votes as well are always very kind of biased to the people who are sharing it and so on.
Brian Kardell: Can we maybe manage to put a U in masonry somewhere?
Rachel Andrew: Yeah, yeah. Hopefully we can actually get in front of some people who are going to say, hang on. That really doesn't mean that here.
Eric Meyer: Yeah. And I mean we've all in this group been involved getting developer feedback and in sort of our pre-recording discussions, Rachel, you made the statement, which is absolutely 100% true, asking for developer feedback is really hard, especially what's hard is asking for that feedback in a way that properly sets the expectations.
Rachel Andrew: Right. I think when we ask for feedback, sometimes we can make it sound like that's the only thing that matters. What do developers think? And of course that usually isn't the only thing that matters. It's why we have such a range of people in the CSS working group, which I think is brilliant. There are browser engineers, but there are also people who really come from very different backgrounds, from web development backgrounds. I tend to think about things in terms of how easy would this be for me to talk about on stage or to write about and explain it to people. And I think when we ask for feedback, that's the kind of thing we're hoping to get is these sort of opinions from people who write about things or who've taught it to their team and they've realized where people struggle, and just what people feel ergonomically works well for them. In order to bring that back as one factor. And I think we have to be really careful about not going out there and making it sound like we're asking for a public vote and we're going to go the way that the most people think because it can only ever be one part of that decision. It's an important one, and we wouldn't be asking so often for people to contribute if it wasn't, but it is just one factor, and I think we need to set those expectations that it might be that actually a lot of people want something to be one way, but ultimately we have to go another because something else kind of became more important for whatever reason, performance or just what's feasible in all of the engines so that it can become interoperable. Yeah, that is an important expectation to set when you ask these things, what are you actually asking and what can people expect when they give answers?
Eric Meyer: Yeah. Let's get into the weeds a little bit. There are at the moment, two main proposals for how to do masonry layout. What properties are we going to have and how are they going to relate to other things? Can you actually give them a summary, Rachel?
Rachel Andrew: Yeah. I think the two main proposals really are do we want masonry to be part of grid so that you end up with turning it on with a value of masonry and then it sort of all behaves like grid layout basically except in one dimension. You essentially end up with a grid that doesn't have rows defined.
Eric Meyer: Sorry, I just want to interject. That would be the default, I guess, but could you also go the other way? So that ...
Rachel Andrew: Yes, I believe that's... yeah.
Eric Meyer: Okay.
Rachel Andrew: Yeah, that's it. You only have it in one dimension. And the thing with grid layout is that it was always defined as a two-dimensional layout system. That kind of sort of would start behaving somewhat differently than you'd expect. The other proposal really is to define masonry as its own thing, display masonry, and then it does its own thing. I think what is important to say is that whichever way it goes, that doesn't mean it needs to become limited in any way. Where it's defined does not impact the features that it has. It really is how do you get into a masonry layout? How do you tell the browser that's what you want to do? That's really what we're talking about with the two proposals is whether you would be using display grid and then you would have a value for columns or rows which was masonry and then use it that way, or would you say display masonry and then you'd have a different set of properties, assuming we were using masonry as the name, to create the column tracks if you're using columns and do things very similar to how you do them in grid layout.
Brian Kardell: Different but remarkably similar names, right?
Rachel Andrew: Yeah. Yes. I guess where we start to get into the weeds is that grid and masonry are different. They're not the same layout method and they're not the same layout method really at a very core level. How it's been described to me really by one of our team is that they're opposite in terms of how the browser deals with sizing and so on. Now that's not obvious to a regular person using grid or masonry. It wasn't actually really opposite to me because I'm not a browser engineer and I had to have it explained to me. When the grid is laid out, all of the items are placed before layouts, so the browser knows exactly what is in each track, and that's really important when it comes to sizing stuff. We need to know how big things are, particularly when it comes to intrinsic sizing. That's autos size things where you're not actually fixing the size of the track and putting something in it and telling it to be the size of that track. With masonry to get that kind of jiggly effect where things aren't in strict rows, the items are kind of placed as they're laid out and the browser doesn't actually know how many it's going to have. Now the browser engineers tell me that this isn't a problem if you have all intrinsic tracks, so all your tracks are auto or all fixed size tracks. When you start to mix the two, it gets problematic because the browser's having to lay everything out and figure out how big it is. And obviously if you get very large grids, that could become a performance problem. Yeah. At its core, the two layout methods, although they don't look different on the surface, they actually are in terms of what the browser is doing, which creates problems. And what that actually causes for developers is that we're going to have to tell you that you can't use bits of the grid spec, in particular, mixing intrinsic and a fixed size track. Something quite common that people do in grid is you might have a couple of fixed size tracks with an auto track that then just gets as big or a small as is needed. You can't do things like that without hitting these performance problems. The concern is that if we bundle the two together, you're going to have to remember which bits of grid work when you're doing masonry, which isn't ideal. It's sort of just something that people are going to have to keep track of. And every time we write about this stuff, we're going to have to explain, if I'm writing a grid layout article for example, and I show a track sizing which has mixed fixed intrinsic tracks to say this is fine if you're in grid, but if you're using masonry, you can't use this. It's an ever case, that feels difficult.
Eric Meyer: You mean it feels difficult to explain to people in a way that they're going to retain it and not end up just complaining about how masonry is slightly broken grid.
Rachel Andrew: Yeah.
Eric Meyer: Or saying, oh yeah, I keep trying to do this thing in masonry that you can, and it seems like you should be able to because you can do it in grid, but you can't do it in masonry. And this sucks and I hate it.
Rachel Andrew: Yeah. And this is really inconsistent, and I kind of remember when we first introduced Flexbox and grid, people would frequently tell me all the time people are saying, oh, this behaves really inconsistently. And what they meant was it had kind of broken their assumptions of how layout worked on the web because they were used to block layout and they were used to the way that worked. And the minute you got into a flex or a grid formatting context, things started to work differently and that was unexpected. And I think quite a few of us did quite a lot of explaining of formatting contexts and what happened when you switched into a different formatting context, that meant that things inside differently. And we've kind of I think got to a point where I don't see people talking about grid being inconsistent with block layout anymore. I think people understand that difference. And so I don't like the idea of then saying, oh, now you're in a grid formatting context, but if you're using masonry, it behaves differently than it does normally. Then it's a whole new layer of potential inconsistency to try and explain. It just doesn't seem as clean to me as having it separately.
Eric Meyer: Right. The other proposal as you say, which is the one that I think you're in favor of is instead of saying display grid and then something like grid template rows masonry or something like that, would just be to say display masonry. And then there would be masonry track property and masonry packing property and things like that, which I would think that the objection there would be we're mostly doing layout things that are already defined elsewhere. Why are we coming up with whole new property names? Isn't that going to confuse people trying to learn when they say, wait, I was already doing columns and rows, but now I have another name that does apparently the same thing?
Rachel Andrew: Yeah, But I think can the values of these things are going to be roughly the same with some allowed or not allowed things that are different across them. And I think it's the values, say the track sizing values are something which I think can be carried over to masonry. And something I was sort of pondering could they be carried over to multi-col for example? Because one of the things we get asked about multi-col is can we have different sized columns? We can't currently do that in multi-col. You split it into columns, they can only be the same size. Could this track sizing be useful there? And I think that the value that the clever track sizing stuff from Grid is probably useful in lots of other things. There may be other layout methods in the future that people want that we might want to use the same kind of track sizing with. I think just the fact that something has very similar values doesn't necessarily mean it should be the same thing. I think we should definitely reuse what we can. And obviously a lot of the things that people see as part of grid are actually box alignment. For example, gap isn't part of the grid spec, it's part of the box alignment spec or the alignment properties are going to be the same because they're not part of the grid spec. They're used in grid and Flexbox and now block layout as well. Quite a lot of the things people are actually wanting, and when I see the discussions aren't even part of the grid spec, they're part of box alignment. And so we already have things fairly well broken down.
Eric Meyer: Yeah. I feel sometimes the actual barrier to understanding is that a lot of these things arose in specific layout specs like Flexbox or Light Grid, and now they're being moved into more generic spots. Basically they've been taken out of Flexbox or grid or even block layout and put into, let's say the block alignment module.
Rachel Andrew: Yeah.
Eric Meyer: Gap was like this, right? There was grid gap, but then basically developers said, that's really cool and it'll work in Flex, right? And it didn't. Then there was a, I can't remember if Flex Gap was ever implemented or it was just proposed, but basically the work group said, let's just have Gap and Gap will work for both of those and it can work in other places maybe at some point. And so I think sometimes that's the learning curve that people have. Someone who's coming to this new doesn't have that problem, they just learn, here's alignment and here's Flex and here's Grid and Grid and Flex refer back to alignment. Fine. But for those of us who sort of learned as we went over time, there tends to be that, oh, that's a grid thing, and then someone says, well, it was, and it still works in grid, but it's not grid anymore.
Rachel Andrew: Yeah, yeah. I think these things are evolving and I think that's something I find really interesting. I've done a fair few talks where I've talked about how things are building on top of other things. Where we've got to at this point is sort of years of work where we're kind of building up on this stuff. I think subgrid is a really good example. There was a point where there was every chance that we would implement, would've specced and people would've implemented a type of subgrid that would've locked the subgrid to both dimensions. You'd have to know exactly how many items you had both for columns and rows to be able to use subgrid, which would've hugely limited things. And I think we sort of hung back from doing that and it took a while to actually get something we wanted. And I think this sort of evolution of layout in particular over the last 10 years or so is really interesting and I think it really shows the value of sometimes waiting a bit and getting a bit more information or waiting until we've just got more stuff happening. Other things have been worked out in CSS that allows us then to move forward and do things in a far better way than we might have done had we just gone ahead with the first idea.
Eric Meyer: Right. We're wandering away from masonry here, but I think it illuminates why this discussion is happening right now where CSS for all the people called it a layout language for twenty-some years wasn't really, it was a presentation language. It didn't really have layout. And then with Flex and grid, it has gotten some layout, the CSS working group, CSS experts, CSS teachers, CSS users are all sort of working out together, sort of feeling our way through how are we going to lay things out? How does layout actually work? We haven't really had that.
Rachel Andrew: Mm-hmm.
Eric Meyer: I think sometimes the hardest thing to explain to people is we're still building this plane as we fly it, even though you might think the language is almost 30 years old, you should have figured this out by now. No, we actually didn't even start trying to figure this part out until five or 10 years ago, and maybe that seems like a long time, but it really isn't.
Rachel Andrew: Yeah. I mean it's really interesting looking back, actually the whole masonry discussion as we started talking about this, it caused me to look back at my involvement with grid because I was looking back to see when I'd first posted about masonry, which actually was in 2017, I'd raised an issue on the working group about people wanted masonry. But I also then thought, hang on, how old is my site gridbyexample.com? And it's going to be celebrating its 10th birthday this year.
Brian Kardell: Yeah.
Rachel Andrew: And it's like, I think for a lot of people, some of this stuff still seems quite new, but we've been kind of talking about it and evolving it and figuring out the use cases, figuring out what's the next thing people need for all of this time with grid and even before that with Flexbox. And I think it's an interesting kind of story and as new people come into the community, they just don't know any of that because they just turn up, they want to build things, grid's there. Yeah, I think it's interesting. I am sort of fascinated by the evolution of all of this stuff.
Eric Meyer: Same with me and Brian. We talk about this all the time.
Brian Kardell: I was going to say, I'm glad that you brought up the history because I was going to also mention your issue in 2017, and it's fascinating that if you look at that issue, if you look back on that issue, which doesn't seem like it could be from 2017, you see you originally say something and you say it feels more like Flexbox than grid, and then immediately Jen Simmons replies and says yes. Also people bring it up to me and yeah, it seems more like Flexbox but maybe also kind of like multi-col and it takes almost no time for Tab Atkins to say you can't do this with grid. It's very different. There's no simple way to adapt grid into masonry because it would involve non-trivial edits to the layout algorithm. I think ultimately we're just beating around this fundamental question for a long time, and when you say it like that, it sounds really frustrating and I guess it is really frustrating, but this is one of maybe 100 things that all of the same people are also working on at any given point in time. The amount of time that it gets in any given at any given moment is really in fits and starts usually, right? Somebody writes a blog post or somebody reinvigorates the issue and then it gets a lot of attention for a little while and then it kind of dies out. That's part of why I think interop is such a valuable thing because it says, okay, nobody's going to lose interest. We're going to focus on this for a year and we're going to take this as far as we can in the year. I do kind of wonder if we had been able to really focus on this starting in maybe 2017 or at least by 2019, because if I recall correctly, I think 2019 we had, to us this working group face-to-face at the Igalia headquarters, and I think that that is the face-to-face where Mozilla presented their implementation and it, again, reinvigorated this, right?
Rachel Andrew: It did, yeah. Actually, interestingly, it's a slight side topic, but one I'd like to mention. That face-to-face, I remember we had a discussion about this reading order issue, which I very strongly felt that we shouldn't be doing masonry until we had a solution for the fact that these automatic layout methods have sort of an impact where they can jumble up the visual reading order and the kind of tab order as you go through the document.
Brian Kardell: Mm-hmm.
Rachel Andrew: And that's something that I'm currently working on and there's an engineer at Chrome prototyping the resulting specification that we've been working on for reading order items, which hopefully would solve that issue. And I think it's kind of interesting that the two have popped up, masonries popped up again at the time when we have actually possibly got a path forward for the reading order issue.
Brian Kardell: Mm-hmm.
Rachel Andrew: Yeah, it was that same working group that I know we spent a bit of time just sort of noodling on how would this reading order switch work? And it's sort of interesting. Yeah, they've come around at the same time.
Brian Kardell: I'm willing to accept hate mail on the fact that I wanted to delay grid until we answered that question because it feels really weird to have a mode for grid that you just say, yeah, but you don't use that because if you re-order things-
Rachel Andrew: Exactly, I feel like there's a whole bunch of stuff-
Brian Kardell: It's there. It's the thing that you always wanted, but...
Rachel Andrew: Yeah. Don't use it. Yeah. And I really hope that we're getting somewhere with this reading order idea that will allow people to do this kind of reordering if they need to. And also then we'll account for these kind of automatic layout methods. Things like dense packing in grid is the other place where it particularly happens. And masonry, we can make sure that we don't just end up creating a really weird disconnected experience for people.
Eric Meyer: You've said that, and I think Jen has also said that people basically saw dense packing in grid land, were like, oh, cool, masonry. And then found out that it wasn't.
Rachel Andrew: Yeah. All of my original demo actually show the dense packing and people in the audience at an event apart would be like, oh, that's masonry. And you'd have to explain that no, it's not. It's doing a different thing. But yes. It's interesting actually, we had a lot of people in the early days asking for masonry, seeing dense packing, thinking it was masonry, saying, why can't we do masonry? And then it kind of just sort of went quiet and people stopped really asking for it. And it seems to have just made a bit of a resurgent and I don't know if that's just trends, people start to see layout methods they want to be able to do because obviously web design changes and what's popular, but it's interesting that it's kind of pop back up again and we're all talking about it again.
Eric Meyer: Yeah. Because there's the proposal that was published on the WebKit blog, and then your proposal that was published at developer.chrome.com. A lot of people probably read all this as just Google versus Apple, Titan Cage fight, only one may leave, but it's really about people who work at Google and people who work at Apple have different takes on how this should get done. I'm just wondering, as one of the people who has the different take, how does that outside reading actually feel of people sort of taking it as Titan fight?
Rachel Andrew: I mean, it's always sort strange when you work for a giant company like Google, people make a lot of assumptions about what actually goes on and when you look into it, all of these companies, it's a very small number of people working on the browser engine.
Eric Meyer: Yeah.
Rachel Andrew: And for layout, it's a very tiny number of people who are working on specs and browser engineering for layout, a small number of people that we can probably all name. We come across them in the working group and so on. It's a very small group of people and I think the reason that we wanted to respond to this is that we kind of felt that the WebKit post did one thing incredibly well. It asked a question that we've wanted the answer to, which is do developers want something more than Pinterest out of masonry? Because what we don't want to do in CSS typically is build a whole load of stuff that no one wants. We want to make sure that when we specify something, maybe we just start with the basics and we can add to it later. We don't want to specify loads of stuff if no one's actually going to want to use it anyway. There was a very important question, which I think the post answered really well because by showing all those cool demos, people are like, yeah, this is stuff we want to do. It is not just the Pinterest layout. We want to do other things as well with it. The problem was it mixed that up with the should this be part of grid? And by doing that, ended up with very unclear signals coming back because when people were saying yes to that post, I think most of them were probably saying yes to fancy columns. They were saying yes to all of this extra functionality. They weren't saying ergonomically this would work best for me as part of grid in the main. I think people were reacting to the demos and stuff. And I think with my sort of writer head on, if that post had been shown to me, I'd have said split that in two. Let's ask the two questions separately. Let's show them the cool demos and then if we want to get a feel for how people would like to use it, let's put that separately and talk about the two halves of the argument because the alternate proposal was already there. And so I guess that was really what I wanted to write, and the team that Chrome wanted was just a more balanced explanation of what the alternative was. That it wasn't, oh, you can't have all of these things if we go with the alternative. It was just that we hadn't got as far as to describe how they would work. And that was there. And it goes back to what we said at the beginning, asking for feedback is really hard and it's, I think, important to break down and be very clear about what you're asking if you want to use that as a signal. Yes, that was really what we were doing. We wanted to make sure that the second part of that question was something that people could actually engage with outside of yes, we know people were really keen on those demos, and it was a great example of a post to get people excited about the possibilities. But I think the second part, which is how will you actually use this, will this be confusing, that then gives us some of that input, which again that's something that needs to be used as one input along with the ability to do this in the browser, whether it's going to perform well, whether it's going to cause us problems in the future because we're going to have to worry about masonry things with every addition to the grid spec in future. Those are the sort of things that we wanted to make sure were made clear, which is why we posted rather than to engage in some kind of internet battle.
Eric Meyer: Right. That last point you made does speak to one of the concerns that I think people outside of the working group maybe don't realize is incredibly important to the working group, which is to look down the road and to say, if we do this thing this way, is that going to close doors or is it likely to close doors? Or is it likely to force us in a certain direction where maybe we don't want to go?
Rachel Andrew: Mm-hmm.
Eric Meyer: Both of the proposals here would be evaluated on that basis, right?
Rachel Andrew: Right.
Eric Meyer: As you've said, if we put this in grid, what is that likely to make possible, make very difficult, make impossible? And if we do it as its own thing, what is that likely to make possible, make difficult, make impossible? Because the working group really does care a lot about leaving as many possibilities open in the future.
Rachel Andrew: Right. Yeah, yeah. We've got that list of mistakes in CSS, the things that we're going to do once we've invented time travel, and yeah, we try really hard not to add any new ones to that, and that's incredibly difficult because we don't know what's going to happen and it's this sort of evolution of things. But yes, I think that to me was when I responded I think to the original proposals in it in 2019, 2020, it was that I was kind of concerned about. How are we going to deal with this going forward?
Eric Meyer: Right. And also we should say that these two proposals are not really new.
Rachel Andrew: No.
Eric Meyer: Some of these discussions have already happened sort of within the working group, but now they're breaking wide, they're going public. People Are starting to become aware of, oh, this could be a thing. And to most people, they seem like new proposals. Really what they are is they're new explanations and explorations of existing proposals.
Rachel Andrew: Yeah. I think actually what this stuff shows is actually that developers are super interested in all this stuff. And are engaged and are wanting to contribute and give their opinion. And I think actually showing our workings a bit is great, and actually showing the rigor that goes into making these decisions, I really think that's a good thing for developers to see that they're not arbitrary decisions and there's a whole load of us thinking very hard about how things should work. And so I think actually these things are quite positive for the community to get involved with and see how it all works.
Brian Kardell: I really like seeing all this happening. The one challenge with it is, yeah, I don't think we know really how to collect the greatest feedback on this because it requires context. Just to give some kind of idea here, we've been having this conversation for a long time, and even as of recently, I read Jen's post on webkit.org and I am like, those seem solid, reasonable points. It seems very lucid and it's not where I would have gone. But yeah, I mean I see what you're doing there and it seems solid to me. And then you read Rachel's and you say, oh, well, also seems very solid. And that's the thing is we know all of us have been thinking about it on and off with some depth and lots of information, and then we want to poll people and get information from people, and we're sort of measuring first reactions.
Rachel Andrew: Mm-hmm.
Brian Kardell: And we're also kind of not doing it in a way that's sort of like AB or practical. I wish that we had some way to, I don't know, polyfill these or something and then say, okay, we're making a decision. Our decision in CSS working group is to not decide on this for six months. And in the next six months everybody go try to use these as much as you can and then write about it, tweet about it, toot about it, and then we'll gauge the sentiment and actual experience off that or something. Because really you don't fully understand something, you don't hit up against its limits until you really try to use it in practice. Some of that is about learning it and learning the ins and outs of it. I do have a follow-up question that's on this point though, which is won't you have to learn either way? You were saying, well, we'll have to explain to people. Individual authors will have to understand that this thing doesn't work with masonry, but they'll have to, even if it's its own separate thing as well, right?
Rachel Andrew: Yeah. Well, I guess to me it's a bit like explaining which of the alignment properties work in Flexbox versus grid, because obviously grid being two-dimensional, all of the alignment properties work. If you are in a flex formatting context though, they don't all work because it's a one dimensional layout, and this is going to be the same for masonry, some of the alignment properties won't work because it's essentially one dimensional. And that I think is when it's a separate format in context, it's kind of cleaner to explain. It's like now you've said display masonry, these ones don't work. I think it just becomes less clear when you're like, well, yeah, you've said display grid, and so all of these work, but now grid template rows has a value of masonry, and so these ones don't work. And even just documenting that on MDN seems hard. Having done a lot of this, digging around with things that aren't implemented everywhere, I think it's one of the problems with breaking CSS down into modules and having modules that are used everywhere is explaining and documenting things that don't work everywhere in the same way. Yeah, I feel like it just adds this second level of explanation. Rather than repeating the story that you have a different display value and therefore these things behave differently. We'd have this two level thing where you've got a different display value, so some things behave differently, but also there's another property here which can change quite fundamentally which things you can use. There's quite a lot of, I think one of the issues is I did a short breakdown in my post, and one of the issues goes into quite a lot of details about the things that are different. And I think something else that is also worth thinking about is just the error cases then have to be defined. What happens if you use something, say you've been using a grid layout and think, oh, actually I want this to be masonry, and you find that then some of the things don't work or you've left them in, what happens to your layout if you've got an illegal value? I just feel, to me, it's cleaner from an explanation point of view. Yes, people will have to learn the differences just like they did between grid and Flexbox.
Eric Meyer: Yeah. That's always the challenge, of course, of teaching something new.
Rachel Andrew: Yeah.
Eric Meyer: Like you say, we had it with grid and Flexbox. I mean, I still see people asking, what's the difference? Which one should I use, right?
Rachel Andrew: Yeah, yeah.
Eric Meyer: If you've been dealing with them for a really long time, it might feel obvious to you what you should use in any given case, but that is because you've worked with them long enough that you've sort of built up an intuition for, oh, in this situation it's probably flex.
Rachel Andrew: Yeah.
Eric Meyer: This other situation is probably grid.
Rachel Andrew: There's whatever. There will be something to learn. Every time we introduce something new into the platform, there's stuff to learn. To me, it's which will be the easiest to explain and to document and to not be dancing around constantly. And I feel that the mix of masonry and grid would lead you constantly having to have a note every time you showed track sizing or whatever, having a note saying, but yes, but not if you're in masonry, which would be less of a problem if you had separate property names and things. It would just be clear. As I say, the MDN docs would be easier to write. That's my day job. I write stuff for developers. And so that's typically with a lot of the CSS stuff, that's how I come at it is could I write this up?
Eric Meyer: I mean, that seems like a perfectly valid and reasonable input signal. I mean, maybe I feel that way 'cause I also do a lot of, or have done a lot of documentation and explanation and presentation in the past. And yeah, I also tend to think about things in terms of how would I explain this to someone who's never heard of it before?
Rachel Andrew: Yeah. And I think it is one input, as I say, and how developers feel is an important input. It's not something that we disregard, but I think for me, it's adding these things up and then there's this performance issue that people are going to potentially run into with larger grids and just these things add up to making me feel that one direction is better. And this is not unusual in working group discussions. So often as you know, things start off with this very simple idea and then people weigh in and it's like by the time it comes out the end, it looks completely different because of all the different things we take into account. This particular debate is not new, it's not a new thing that's happening. We have these debates on a weekly basis in just sometimes more smaller things or whatever.
Eric Meyer: Yeah. It's not really unusual at all.
Rachel Andrew: No.
Eric Meyer: Maybe it's a little unusual in the way that we have these two blog posts that are sort of introducing it to the wider world, but in a way, this is sort of giving the wider world a little peek into how the working group actually does deal with things.
Rachel Andrew: Yeah. I think that's it, and that's something to definitely get across. This isn't kind of a fight, as you mentioned before, it's not a fight between Chrome and Apple or the Safari or the WebKit and Chrome. It's very much just a working out of this stuff. And because now as soon as the WebKit Post went out, developers were involved, and so we wanted to make sure that we clearly defined the alternative point of view. But as I say, this is the sort of thing that we do in the working group all the time is try and figure out the important things in two or three or more competing viewpoints on how something should happen. And there's usually excellent stuff in all of those viewpoints, and it's figuring out how that's all going to work together. That's the work, that's what we do.
Brian Kardell: Yeah, it's tricky from the outside. Things do get sort of one dimensionalized sometimes. We have this tweet or a position that somebody takes that gets a bajillion likes and boosts, and so that thing is popular in the mind of all those people. And then that's not the way that the CSS working group goes, and you say, hey, don't listen to us, priority of constituencies, but you're supposed to listen to us. But it's one of a lot of things and also a thing that it sounds bad in a way, but it's also true, which is sometimes developers aren't the best at that kind of stuff.
Rachel Andrew: Mm-hmm.
Brian Kardell: Two that I think are good examples of this are CSS custom properties, which developers asked for basically string replacement for since the late nineties, you know what I mean? And we didn't get that because Tab came up with a better idea, and it's the fact that we came up with a better idea that made it plausible in the first place.
Rachel Andrew: Yeah.
Brian Kardell: And I think it is a much better thing. And it's super popular now, right? Super popular.
Rachel Andrew: Yeah. Oh yeah. Everyone.
Brian Kardell: The other one is Layer. The other one is Layer, because I don't know if you remember, but there were so many people who were like, the cascade is terrible. It's the source of all evil, and really there's this kind of revolution happening. And Mia took a look at it and came in and said, okay, what if the solution is more of the same? The solution to your problem is actually more layers of cascading.
Rachel Andrew: Yeah.
Brian Kardell: I think that was in the same working group face-to-face in Spain.
Rachel Andrew: Mm-hmm.
Brian Kardell: And I remember saying, I kind of get what you're saying, and I think it is a really good idea if I also worry about how that will be received.
Rachel Andrew: Yeah.
Brian Kardell: But it is great actually. It really does help with those problems, and I think I'm really glad we did it.
Rachel Andrew: Yeah, yeah. I think-
Brian Kardell: Even though approximately no one was asking for it.
Rachel Andrew: Yeah, that's it. And I think it's an amazing thing to be involved with. I mean, the people who are involved with CSS. I mean, you mentioned Miriam who has done just some amazing work, things like container queries and stuff that developers have been asking for forever. One of the great joys of being on the Chrome team is just working with these engineers and the insights they have and their ability to spend time answering questions and figuring out what the best way to do things is. It really is. And as I say, I like the fact that sometimes we bring it out into public and say, these are the discussions we're having. Because I feel that personally it's been such a gift to have been involved with this. I don't even have a computer science degree. I don't have the obvious background, and I've learned so much from being involved and talking to these people and trying to understand. I just think it's cool when other people get to see a bit of that and then kind of understand the complexities that go into it.
Eric Meyer: Yeah. And how just almost intimidatingly smart, the people who are working on it, thinking about it are. Like you say, it's been a gift for me as well, and a real joy to be nowhere close to the smartest person in the room, but be there when the really smart people in the room have these discussions about how should we fix this problem the people have with the cascade, or how should we fix this deficiency in CSS layout, or how should we fix that people want variables and we don't have it, whatever it is, right? And sometimes it can be a few years because we're not all sitting in a room 24/7 or even 45. It's not a full-time job for anybody to work out this stuff. It's a few hours a week. But that gives some of these things time to simmer sometimes on the back burner, sometimes on the front burner, and maybe come to a realization of, oh, people have this problem. People don't like the cascade, so what if we came to them and said, hey dog, we heard you hate the cascade, so what if we put more cascade in the cascade? And that turns out to actually solve their problem, the thing they actually like.
Rachel Andrew: Yeah. It comes back to this thing of just the fact that we are building on top of things all the time, and sometimes container queries is a great example. For a long time we're like, we can't do this. There's no way this can happen. And then of course there was containment and that just gave that step that moved it along, and this happens all the time. One thing builds on another and then it looks like this thing just pops up and suddenly becomes interoperable, and everyone's like, hang on, you said this couldn't be done. And now suddenly here it is. And actually there's years and years and years of work and discussion and little steps being made that made that possible.
Eric Meyer: Yeah. When you asked it wasn't possible, but then we spent seven years laying the groundwork to make it possible. You're welcome.
Rachel Andrew: Yeah. It is fascinating and it is, I say, a gift to be part of and to actually see this happening. It really is wonderful.
Brian Kardell: You said this is no one's full-time job. It's like sometimes it can be a full-time job for a limited period of time. You focus on this, and one of the times that that happens is CSS working group. Sometimes we have a face-to-face or breakout session. There's a whole day on this one topic, or that doesn't sound like much, but so much happens when we get together and focus. And then during implementation, of course, there's always refinement. We talk about that a lot of times, like write a spec, the whole group agrees like, okay, we even have an implementation, and it's like, we think it's done then. No, this is very much almost 80/20 rule where we think we're really complete. And then the second implementation comes along and says, oh, wait, I have a million questions.
Eric Meyer: Yeah, yeah.
Rachel Andrew: Exactly.
Brian Kardell: And you think, oh, thank God. Now they're all worked out. And the third implementation comes along and says, well, what about...
Rachel Andrew: Yeah.
Eric Meyer: Well, Brian, did you have any other questions you wanted to...
Brian Kardell: I don't. I just wanted to say thanks so much for coming on. I like when we get to ask questions of developers and then try to explain the sort of nuance and the background and the history, and it's fun. Thanks for coming on.
Rachel Andrew: Yeah, it's been a really fun chat. I mean, I do like to nerd out about these things, as you know, so it's been a nice way to spend my Friday afternoon.
Eric Meyer
Brian Kardell
Rachel Andrew