 Before, it's like you had to design stuff in Photoshop and then export everything, but now everything seems to have evolved quite substantially. Forget everything you knew before, forget about slicing images, forget about generating images, you can just use text and just load the topography that you want. Layout in CSS in the web has changed quite substantially from when I started. I remember it was like table layouts and stuff like that. Would you think about the evolution of layout on the web? I guess we've learned from print and we've taken their technologies or their paradigms. And we're just trying to make it work for everyone in the browser instead of just his print, his browser with this never-ending stream of text. That works very well for doc processes, but possibly not for documents that people want to read. But I think it's, apart from painful and long and draggy, I think it's very exciting now because you can't predict what people are using or how they are reading that. So you have to be designed for this wide gamut of options. And I think that's very interesting that layout is finally supporting you in that so that designers don't hate browsers. What do you think about CSS Grid and Flexbox? I think that's generally exciting. Flexbox got up to a bad foot because there were three or four implementations, I think two or three. And none of them were really compatible, so that quite didn't work. With Grid, I think we learned a lesson and finally everything gets together at the same time with all the browsers. So that was good because it supported phones, which is what most people used to browse. So it makes it so much easier. Like once you grasp how it works, it's very easy. Whereas with floats and all the things from your, it was really, really hard to do. And you had to add lots of extra markup that makes it very hard to maintain. So nowadays you can have very simple layouts, which are very easy to understand and maintain, which I think is important. It's not just like building it, but also being able to change it afterwards. And not having to add more and more CSS to override the previous CSS. I remember when I first was getting into coding, the thing, the tool that really helped me understand it was like when Firebug was like the first developer tool, and then Firefox had the developer tools integrated. And that really was like, it was a harmony. Now I understand the box model. Now it makes it... Yeah. When I saw the developer edition, like the layout tool for Firefox, I was like, this is amazing. Now I can finally see, like visualize the code, which I always found was like, why haven't we had this tool in the beginning? Like this is exactly makes perfect sense. Like at the beginning, the tools were basically for the engineers and the browser to be able to diagnose what's going on there. But now we are the lots and lots of visual features to like, you know, like CSS to the engineer and everything. Yes, you need to diagnose. And I have seen tools that engineers have built where everything's flashing. Like using like all these relay outs or these redrawings, but that's not actually useful for designers. So that's why we need designers to be involved in designing the tools as well. So that we are giving you tools and information that is what you actually need rather than what the engineer needs. Like the engineer maybe just needs to diagnose how many phones are there in the system and how many clips do they have. The designer doesn't care about that. The designer might want to see what you were mentioning, like variable phones. What can I use here? Where are the things I can change? I think that's very interesting. Like it just takes us from as browser maker. It just takes us from like, OK, I'm an engineer providing you this feature to you. So, OK, how can I make this feature useful and accessible to you and so that we can all work together and you can make best use of this feature. I have implemented it for you because there is no point in implementing a feature if no one is using it. But the thing with tools is in typography it's like the thing that ruined it for a lot of typographers is when Photoshop and these design tools made it really easy to change the font sizes. Because back in the days like you wouldn't have a specific font for font size 14 and the metal plates would be very different for 18 and whatever. But then when you had the design tools you just changed the size. And almost for classical typographers for this is really irresponsible. You're destroying it by creating these tools. We've reached a similar point now with variable fonts where you have a typographer designs all these settings and you expose this to the developer. They could end up doing really bad things like things which are illegible thinking, ah, this is really cool. So as a tool maker, I mean, what do you what are the considerations that you think that you need to think about? Okay, on one hand I'm very open to people going totally wild and just like getting creative because that's part of what motivates me to work on Mozilla. I want everyone to be able to do whatever they want to do on the web. Like if it's tacky and ridiculous, all the better. Just think 90s, GIFs, colors, all very psychedelic. I'm fine with that. We look back on that and we're like, oh, those were the times. Once variable fonts get in, we will be like, ah, this was so much fun. And then people would go back to very minimalist and very composed websites. I am not against that. But then if I get into this kind of maternalism mode, I'll be like, okay, let me help you. And let me tell you, maybe you want to build a tool that says, hey, maybe you're adding too many variations of this font. This can be a bit overwhelming for people with certain disabilities or this is not readable. Or, you know, kind of like the two sides. You can be very creative on the web and also maybe you can advise people they can take or not the guidance. But as browser makers, we have this unique insight on this is not going to work well in certain circumstances. And I think also, as most of you know, we have this responsibility to be like, hey, you know, some people can't withstand this kind of like flashy colors. So we can maybe warn the user. We are not doing that yet. But we are maybe thinking of maybe doing that because you know what's been rendered and what has been passed. So, you know, the features are active. So we should use that data instead of just like possibly display the output. You want to give the users of the browser, which may be the developer, which is slightly different for the tool side. You want to give them the control and power, but at the same time making sure that they consider the real users of the tech. It's also cool because with the newer features that were added to animations in CSS, you can control them with JavaScript. So you can do things like, well, this user has selected not to have animations. So if they've had selected to have less motion, I can reduce the animations, go back to a more consider and compose kind of typography and distract them less so they can be more, you know, able to access the content without being interrupted by my flashy creativity. So I guess it's cool that we are giving them all this control, but also we need to let them know that there is all these considerations that you have in mind. It feels like we're in the golden age of our sort of industry. So maybe Flash was kind of like the article era and we're now in the wild west. We just need some more time and give maybe more libraries, more support and also, I guess, giving people the license to just whatever they want. Because otherwise it's like, you know, the JavaScript police comes and says, like, you're doing this wrong. This is not how it should be done. There wasn't that much of that in the Flash era. So people were giving themselves the license. No more free creative. Yeah, because people were not like looking at your code. Look at using that library. That's terrible. Yeah. Yeah. So I guess we're missing a bit of that kind of tool set for creatives. But at the same time, I think the layout tool that is in Firefox, I think that's the future. Like where people bridging the gap between turning the browser into a design tool rather than just a consumption or viewing tool. Yeah. And I think that's where once that is nailed, I think everything will change or fall into place, perhaps. Yeah. I mean, that's one of the things that we're trying. And I guess Chrome and Edge are also trying like every time you publish a feature, you want to make sure that the support and the tools is there. So that it's exposed users and they can, you know, work with it and edit and also every person learns in a different way. Yeah. So some people might prefer some visual tools or people might just prefer code. Like some people like clicking or just like typing. So I think it's very cool that we're showing this kind of like visual interface for designers who are thinking of layout, not just thinking of column and tracks and names of tracks, which is very abstract. So I guess that's just the first step. We are now talking like this to these screens, but then you're like, what happens if we take reading into 3D? There are all these means that we can use. It's interesting to start thinking about how do we design tools for inspecting 3D worlds that make sense. Yeah, like even because it starts involving like attention and psychology and like all this, you know, like all the science of perception. Like if I'm looking at you, if you were a WebVR object, if I'm looking at you very intensely, I guess I should be double clicking at you because that's what it would be conveying. But like, maybe I'm just like glancing at things and it doesn't mean that I'm interested. It means that I'm like curious, but how do you, yeah, yeah. So it's like, it's interesting, scary as well. People tend to assume that their customers or their users are all like them, but you have to get out of that mindset. And it's really injurious to the health of the web if people just code for one browser.