Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--how works CSS4 and React--Rupert and with me is Chris--thinking face emoji--Coyier.

Chris Coyier: Whoa!

Dave: Hey, Chris. How are you?

Chris: Inside baseball, there. That's great. If anybody got that joke, you get 100,000 points.

Dave: If you wrote the comment, you also get 102,000 points because I appreciate the -- there's a good, honest question in there, I believe.

Chris: There kind of is, honestly. I hate to poke fun at it too bad -- although, not really.

Dave: Yeah.

Chris: The last two, maybe more, plus episodes, we've just turned this show into, like, we're just talking about browsers. We can't stop. We can't help ourselves. It's become the browser show. I think we named 399 The Browser Show, and now that's over and it's episode 400!! What?!

Dave: Yay!!

Chris: Woo-hoo!

[Applause]

Chris: Oh, my god. What a milestone! You know there are only 52 weeks in a year, so we're edging up on 8 years of doing this show. We're probably actually over that because of the weeks that we've skipped. It's an incredibly long time to do a show, so thanks so many for the people, no matter how long you've been listening. That's really cool and we still love you.

Dave: If you've listened to all 400, you get 400,000 points.

Chris: Yeah. I don't know if there are enough points to give you. But I bet, or I know, as a matter of fact, in this last run-up of shows where we can't stop talking about what browsers are doing, there's probably -- well, I hope there's been some interesting stuff and probably some, depending on who you are, cringeworthy moments where they're like, "Eh, they're not getting that right." That's partially because Dave and I don't work for any browsers. We don't have any particular, other than casual conversations, little Slack convos here and there, don't have any particular inside baseball knowledge on what browsers are doing. Our knowledge comes from blog posts and just yapping our mouths about what we think is going on.

In this episode, we're going to fix some of that, I hope, because we have two amazing guests--both have been on the show before--that quite literally do work for browsers and probably have roles that make them extremely knowledgeable about what's going on at browsers. We have Jen Simmons. Hey, Jen.

Jen Simmons: Hello.

Chris: Hey.

Jen: Congratulations on 400 shows. That's huge.

Chris: Yeah. Thanks. Thanks so much. It feels good. We were going to shortly coincide the release of this with a new website as well, although that's a deadline, so now I've guaranteed that we're going to blow past it. Oops, sorry. But it's coming.

Dave: Hey, episode 404 looks really great!

[Laughter]

Chris: It's looking good. Full of SVG and ASCII and Glitch. Oh, god. It's going to be weird.

Jen, you're at Mozilla, yeah?

Jen: I am at Mozilla, yes, the company that makes the Firefox browser.

Chris: Mm-hmm. Role, I'm sure it's specific, but is it just Dev Evangelist, or is it more specific than that?

Jen: Yeah, Developer Advocate or I like calling myself Designer and Developer Advocate because I think of myself as an advocate for all the people who make websites, not just the people who write the code.

Chris: Oh, lovely. Okay. We also have Adam Argil. Hi, Adam Argyle. Sorry.

Adam Argyle: Yo, yo, yo. Yes, Argyle. That's cool, though. Argil is when they would call me on the phone and be like, "Hi. Is Mr. Argil there?" I'm like, "Sorry. No, there's no Argil here. You have the wrong number."

Chris: I did an instantaneous footnote. [Laughter] Yeah, right.

[Laughter]

Chris: You screwed that up. You're not friends or family, so byeee.

Adam: Yep. No worries.

Chris: Adam, you are at Google.

Adam: I am at Google. Yes.

Chris: Yeah, and also have a probably complicated job title but is in the realm of developer evangelist. Yeah? Advocates.

Adam: Yeah. It's kind of funny. Just like Jen, I like to represent designers and sort of more than just engineers. Yeah, mine is Chrome CSS and UX Dev Rel. Oooh!

Chris: Ah, that's right. You get CSS in your name, which is to the envy of a lot of people, I think. Wow. Cool. Cool job. Both of you, excellent jobs and work for very different companies in a lot of ways, but predominantly, I guess, for this show, literally different browsers and perhaps two of the or definitely two of the biggest last standing browsers.

Last standing is just maybe an unfair way but just, you know, we kind of lost Edge, in a way. Edge is still around. Microsoft is still around, of course, but they now use Chromium, so it's not a rendering engine. Somebody fix my words for me there. What am I saying?

Jen: I think you're trying to say that there are two rendering engines. One being Blink, which then is what Chrome uses, Google Chrome. Now it's what Microsoft Edge uses. It's also what Samsung Internet uses, Internet browser. There are a whole bunch of browsers, actually.

Chris: That's what the Payday Lender Opera uses.

[Laughter]

Dave: Doh! Spicy.

Jen: QQ. Everyone forgets to talk about the QQ browser, but that has a huge market share in some markets.

Chris: Also Blink, yeah, or Chromium, or whatever?

Jen: I think most of those are all like Blink or forks of Blink or forks of Chromium.

Dave: Brave. Vivaldi.

Jen: Yes.

Adam: Yep. Yep.

Jen: Then you've got Gecko. Gecko drives Firefox - pretty awesome. I sometimes remember that Gecko Mozilla came from Netscape and Netscape came from Mosaic, so it's this kind of legacy of the original GUI browser. Not that it's the same code because it's totally not the code.

Chris: Mm-hmm.

Jen: It's been a browser that's been around for a really long time.

Chris: Yeah, there's the lineage.

Jen: Yeah, there's a lineage and was really--

Dave: Powerful, ancestral origins.

Jen: Yes.

[Laughter]

Jen: But then there are really three rendering engines because WebKit is also a really important, powerful rendering engine.

Chris: Right, and we know Blink came from that, but has it been long enough that it's just different now, like the lineage? It's cool to know that the lineage is there, but it kind of doesn't matter anymore.

Jen: Well, I think that's a good question that we could get into. Does it count? Does WebKit count as a third rendering engine or is it just too--?

Chris: Well, it has to because it's the only one that's on the fricken' iPhone.

Jen: Yeah, and then WebKit then drives--just to close the loop--Safari, which also means iOS, Safari on iOS as well as Mac. Actually, every browser on iOS, when you open up that browser no matter which company logo it is that you're clicking on, is running--

Chris: Edge, Firefox, Chrome.

Jen: Yeah, it's running Safari.

Chris: They all actually run WebKit under it, right?

Jen: Yeah, or if you open up Facebook or you open up Twitter and you click on a link and you stay inside that app and you're looking at that webpage inside that app, you're also running on Safari Web browser technology, basically.

Chris: I hate to say this, but as somebody who has to write words professionally about all this sometimes, sometimes I just give up and I don't try to use the right -- like, am I talking about a rendering engine here or am I talking about the open-source project or am I talking about a sub-part of the thing that runs the thing? I just say, "Chrome, Safari, or Firefox." I just use those words instead, which probably makes me sound a little dumb sometimes, but I feel like there's some clarity to that.

Dave: I think most people or even developers might be ignorant to the engine differences and they only know the end product that you can install. You know?

Jen: Well, you know, I would have expected when I started working for Firefox that I would learn more and more, which I have, and that I would know for sure better and better, and I do not know for sure better and better. [Laughter] It just gets more and more and more and more and more and more complicated, actually - any of it.

Chris: Sure.

Jen: CSS, understanding CSS, understanding exactly what is the difference between the rendering engine and the browser itself. Samsung Internet browser, for instance, is a fork of Blink or maybe a fork of Chromium, and so you go to a website like Can I Use, and Samsung Internet doesn't always have the exact same data as Chrome because I think they shipped Grid six months later or something.

Chris: Really?

Dave: Don't they kind of freeze their versions, right? I remember Chrome was on mid-60's and they were stuck on 48, 52, or something. I think they do that just purely out of, like, it's one of the top-selling Android brands. I think they kind of have to move a little bit slower. Is that the idea there?

Jen: That's my guess. Maybe Adam knows better, but that's what my guess is. They're just careful. They don't want to ship something to a whole bunch of phones, especially in lower-powered phones, cheaper phones that might be slower.

Chris: You wouldn't want to break CSS Grid with a release. That'd be crazy.

[Laughter]

Jen: Yeah, I think they were kind of conservative about shipping Grid because they wanted to make sure that it was going to be fast enough, that the slowest phone that Samsung puts out could handle Grid, which it totally can and so they shipped it. But they took a little bit of time to make sure. Yeah, look at … right now. Samsung Internet 10 is the current version of Samsung Internet, not 80, which is the current version of Chrome and Edge. Yeah, I guess they've got different numbers. I don't know.

It gets really complicated. All that is just to say, I don't feel like anybody is an expert for real, for sure. We're all stumbling around.

Dave: Yeah. I was surprised Edge picked up the -- [Laughter] you know it went from like Edge 17 to Edge 79, or something.

Jen: Oh, right. [Laughter] Yeah.

Dave: You know, so I was surprised that Edge picked up the Chromium versioning, but it makes sense for them.

Chris: I like it. I'm glad they did it. Okay, so one of the first things in my notes here is that what makes this so fascinating and perhaps unavoidable on a show like this is that y'all, Firefox and Chrome, release browsers pretty regularly. It's a month-ish, right, in versions these days on both sides? Maybe six weeks, sometimes.

Adam: (Indiscernible) Yeah.

Chris: Yeah.

Adam: Sometimes it's nightly, right? We've got Firefox Nightly. You've got Canary where it's hot.

Chris: Yeah.

Jen: Yeah. How often does Chrome come out, Adam? Do you know off the top of your head?

Adam: Ooh, no. I think, though, it's once a month or something like that and they're about to bump it up. They're about to double-down on releases.

Chris: I think they think about it nicely. Not to put words in your mouth, but I was looking at the dates of upcoming releases for both recently and they're not -- it's not just some set in stone thing. I feel like somebody actually [laughter] thought hard about it and dealt with holidays and dealt with, you know--

Jen: Yeah.

Chris: --internal stuff so that the dates were actually intelligent. I think it's not -- four weeks is short and six weeks is long. It's in the middle, generally.

Jen: Well, Firefox was six weeks, I think, was the number that we were shooting for and it was adjusted for holidays and such that we weren't shipping a browser on a Friday afternoon.

Chris: Right.

Jen: Or shipping it and then going off to some vacation for whatever. So, it wasn't always six weeks. It was sort of six to eight depending on holiday schedules. But we just bumped it up so, in 2020, starting in January, we have sped it up. Go faster. The go-faster initiative. Now we're doing it every four weeks.

Chris: Oh, wow! Okay.

Jen: It's a little faster than monthly, actually. Yeah.

Chris: When both Chrome -- as I speak here, the latest release is 80, I think, and Firefox is 73 or whatever. When a blog post comes out with a browser release, even though they're so fast, they're only monthly, it's packed! There's tons of stuff.

Adam: It's packed. Yeah.

Chris: It's packed. It's amazing! I say that in a good way, like, "Wow! There's something in here for everybody," because my last thought in looking at all this is, like, there are so many different kinds of developers and developers that work on different projects that care about different things.

There's something for everybody in these browser releases, both really impressive. You look through some Firefox notes and be like, "Oh, my god! Independent transforms shipped. Sick!" You know? What a nice thing.

Adam: Ooh, yeah.

Chris: Or you look through Chrome notes and be like, I don't know, "Some cool new contact picker API shipped. Oh, sick! What a great idea." They're different, but that's always been the case. Browsers just work on different things. That's just the way it is. You know?

Jen: Yeah. Yeah, and it's funny, too. Safari, I think sometimes people think Safari comes out once a year. But if you've really been paying attention, at least my personal observation has been that they release a lot of stuff the rest of the year. They have their big operating system release with a version number change, so to go from 12 to 13 in the fall, but there's usually some sort of a bigger release in March and then there are all these point releases. Sometimes there's a lot of stuff packed into a point release when you look in their release notes.

I think that it's really just changed for all of the browsers, it feels like. I don't own -- I don't have an Android phone, but I imagine that it's also true on a lot of these other mobile browsers is that things are just constantly changing. There are constantly new things coming out. As a Web developer, if you're wondering how supported is this particular piece of technology that I'm considering using, you really have to go look it up at whatever given moment and realize that it's probably going to change fairly quickly or there's a chance that it will change fairly quickly.

It's not like ten years ago where we waited an entire year for a new browser to come out and that browser had sort of all the things and then nothing would come out for another year or sometimes two or three years. Yeah, it's just a very different environment where things are constantly changing and it makes it hard for developers, I think, to kind of keep up. I think people feel overwhelmed by that, the fact that it's always changing.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by AWS Amplify. You know AWS, Amazon Web Services. It powers most of the Internet, it feels like. There are a ton of things that go in the AWS bucket like EC2 allows you to spin up servers of your choice and has all kinds of configuration. S3 is for file storage. Lambdas is for running cloud functions. All kinds of stuff that, individually, you can set up and use and are great, but there's so much more than that. There are a ton of different things AWS does.

AWS Amplify is kind of a package of tools to help you build full-stack apps for the Web. It's like, just give me the stuff that I need that usually, you need to build an app. Amplify is hosting. You need Web hosting? It's got that. It's got authentication for logins for your users.

It's got GraphQL as a first-class citizen of it. It's got serverless functions like I need the Lambda thing. I want to run some code in the cloud to hit APIs and do whatever else I need to. It's got file storage if you need it. It's got some machine learning stuff in there if you need it.

Amplify is this easy to use, full-stack framework for getting started quick with building Web apps. It's really cool. The auth stuff alone is cool. It's just a few lines of code in there.

GraphQL has taken over the world of how to get things from a database, put things back in a database, really front-end development-friendly way to do database stuff. Love GraphQL. It's just built-in as a first-class citizen. It's this scalable API. You don't have to provision your own servers. It just does it up for you. Pretty cool.

ASW Amplify is really cool. Definitely worth checking out, especially as a front-end developer. Check all that out.

[Banjo music stops]

Chris: One of the points I wanted to see what you all thought of, this is just what it seems like to me. It seems like there's some truth to this that in those release notes, in the evolution of browsers, it seems like of the major three languages that browsers speak--HTML, CSS, and JavaScript--and I know there are a lot more than that. There's HTTP and SVG and PNG and all kinds of stuff that are technically sort of like languages that browsers support. But of the three ones we talk about the most and matter to Web authors probably the most is HTML, CSS, and JavaScript. It seems unquestionable that JavaScript moves the fastest.

I mentioned that contact picker API. That manifests itself as a JavaScript API. I don't think that probably has anything at all to do with HTML and CSS, really.

You see the release notes. There's always JavaScript stuff. The language itself moves. APIs move. New ones come up. Things are improved. There's just a lot happening in JavaScript land. You know, fine.

CSS moves perhaps in the middle. We get new stuff. It's a little slower, but there are still exciting releases and stuff that happens.

Then HTML seems to me moves the slowest in the fact that almost never at all. Chances are, you read a release notes from a browser release and HTML is not in there. HTML doesn't do anything. [Laughter] Is that fair or is that a weird, bad characterization?

Adam: No. You're reminding me of Jeremey Keith. He's been on stage. He's got that awesome graph where he's like the speed of JavaScript is super -- what does he call it, too? It has a cool name. Anyway, he's just an amazing speaker.

Yeah, he's got a great graph that shows how these things don't move at the same speed. He talks about the advantages and the disadvantages of it. Maybe we'll link it in the show notes. I think he explains it really well. It makes sense and it's okay. I don't know.

Chris: Yeah. Yeah. Yeah, I'm not saying that's a bad thing, necessarily, but there's been more chatter lately that maybe it's, okay, fine. It's supposed to move slowly, but maybe too slow is a problem too because there are plenty of things that have been identified that just would be nice to see happen at the HTML level.

We're seeing some of that start to happen, it feels like. At the end of the last show, Dave and I were like, "Oh, my gosh. What a week." This might as well be the HTML imports show too because we end up talking about those forever as this part of Web components that kind of died that Dave feels pretty strongly about, I think is fair to say. We saw some movement in that. Dave had some thoughts, but it's interesting to see that being talked about again. Let me just set that down for a minute.

We also saw a big discussion about container queries get kicked off and how much -- you know there's a very clear high amount of interest in that amongst the CSS community. To have, all of a sudden, that being looked at very seriously and having some agreement on some things, it seems like, from the outside anyway, like, "Wow!!" You know?

We've seen -- all of us, I think, have seen Nicole and Greg on stage talking about -- Greg is from Microsoft and Nicole is from Google, so that's immediately interesting anyway to see kind of browsers cooperate on things. They were talking about inputs - maybe only second to container queries, in my experience, in the CSS community. CSS people are like, "If I could have anything in the world, what I want is to be able to have some styling influence and maybe even behavioral influence over HTML inputs."

I don't know. That was a lot but, wow! Stuff is happening.

Adam: Stuff is happening.

Jen: Yeah. I think one thing that's interesting to me, having joined the CSS working group, now I guess about four years ago, and starting to understand more about what's happening with some of the other working groups or the browsers is that there's this odd combination of different priorities or desires--motivations maybe is the best word--different reasons that pieces, different technologies get created. One of the mysteries of and one of the beautiful things about the Web standards process is there's this way in which all these different people who are companies, organizations who have a stake in what's going on, on the Web, come together and then their interests are being represented. Some of those interests are really great and totally aligned with what the Web needs or users of the Web need or authors, people who make websites need. Sometimes they aren't in alignment. Sometimes it's like, well, this company needs this thing, this country needs this thing, or the people who make this type of device need this thing. Therefore, it's going to happen because they are putting employees on it and those employees are putting their time into it.

I don't know. When I was working as a developer when a new CSS would come out, I just would sort of trust that it came from some sort of like Moses coming with the tablets down from the mountain. Something comes down from the mountain on a CSS specification tablet and is handed to people who make websites. There's something mysterious and perhaps even divine about that process. Not literally, but something that, when you take a group of people who have different interests and you toss them together in a context where the process is working fairly well, that somehow magic happens. What ends up getting invented or created is more than the sum of the parts. It's more than the individual people in the room would have come up with. It's better than what they would have come up with or it's more than those individual companies and what those individual companies wanted.

In some ways, you could say, "Sure. Why are we getting so many JavaScript APIs right now? Is this a good thing or not?" Well, some of it is that maybe it's because that's what needs to happen. That is what's good for the Web. It's bigger than any of us. It's bigger than all of us combined. It's just the direction in which we're going.

Some of it is perhaps like, oh, well, you can trace it back to this particular company, this particular group, or this particular campaign that's saying, "We must have this. We must have this. We must have this. It's important. This is important. This is important. This is important."

I think part of what should happen if a Web standards process is happening well, if it's happening in a healthy way, if it's happening in a way that ends up with something that's greater than the sum of the parts and is magic and is the best for the Web, then that process needs to support a kind of back and forth so that no particular interest of a company, a group, or campaign is taking over and dominating in a way that is actually bad for the Web.

I think in some ways it's like, "Yeah, do we want this? Do we want CSS to be slower right now? Do we need more out of CSS? What could authors, people who make websites, Web developers, what could Web designers do to demand more of what people who make all the websites actually need and a little bit less, perhaps, of what certain agendas from certain corporations want?"

I don't know. There's an interplay in there. Not to say that anything, in particular, is bad or anything is particularly great or good, but attention needs to be paid, I think, all the time to make sure that that process is in fact healthy and that it's not going to get dominated by one particular massive player who just has an incredible amount of power because they have so much money. That would be bad….

Chris: Yeah, some of that, I guess I tend to ignore if something gets shipped that is not for me as an author because you look at these really long browser release notes and probably 70% of it I'm just like, "I guess I kind of get it but I don't really care." Then there are a few things that I'm like, "Whoo! Nice!" But that percentage is different for other people. If some kind of corporate-sponsored fancy thing had to go down, I would just shrug and be like, "Oh, well, whatever. I didn't need it."

You're saying we should be critical of that to some degree because the few people on earth that write the code that makes those things happen could have been doing something else that's perhaps a little more useful.

Jen: Oh, I wouldn't say that. For instance, a couple of weeks ago now, maybe. There's this funny day where suddenly both Microsoft and Samsung were announcing devices that fold and screens that fold, right? Those flip phones, the resurgence of the flip phone and then Microsoft has that Surface Tablet that folds in half. Only--I don't know--like five days before that, in the CSS working group meeting, Microsoft presented a proposal for adding something to CSS so that authors can -- sorry. I keep using the word "author" but I mean Web designers and Web developers.

Chris: That media foldable - whatever?

Jen: Figure out where the fold is. Yeah! It's unclear whether it should be a media query or if it should be an environmental variable, but some sort of a tool--

Chris: Sure.

Jen: --so that people can kind of know where the fold is and do a layout that reacts to that fold for whatever reason.

Chris: One way to look at that is, like, "Uh, cool. I guess we have to deal with your weird device now," but we've seen that before like when Apple ships the Notch and we've got to have new CSS to deal with the notch.

Jen: Right. In the middle of the meeting, because I didn't really know what I thought about it, so I tossed a tweet out in the world and was kind of like -- because my first sense was that, "Oh, Web designers aren't going to care about this. Nobody cares about this. This is the hardware manufacturers who care about this."

But I wanted to hear if somebody did have use cases or did have something where they were like, "Oh, that's awesome! I'd love to do it. Here's my idea," because I wanted to be able to not just think about it myself. I wanted to know if other people had ideas.

Most of the tweets came back, they were like, "Uh, total waste of time." "Ugh. I hate it. I'll never use it." "Um, I can't believe you all are putting effort into working on that."

I was like, oh, yeah, but that's not how it works. The effort put into defining a media query or an environmental variable for folding screens and then implementing that in the browsers that need it is not going to derail something else. Believe me, those are -- you know, whoever at Microsoft -- I mean I don't know this for sure but, as a person just guessing from the sidelines, whoever at Samsung and whoever at Microsoft who wanted this thing to happen is not going to be like, "Oh, never mind. Don't do that. Why don't you go work on overflow fragmentation instead?" That's actually a bad example. "Why don't you go work on, like, underline styling instead?"

Chris: Okay.

Jen: It's not a zero-sum game, so I think it's fine. Yeah, sure, let's spec that stuff. Maybe it will turn out that those devices will never take off and maybe it won't be a thing. Ten years from now, we'll look back and go, "Oh, yeah. we got that little thing."

Chris: Because it kind of manifests itself. Like if we do that, then we have precedent for the next time it comes along, too. The next time it'll be even easier because we have some commits we can look at of how it went last time.

Jen: That's why we got CSS Grid because Microsoft was very interested in having something in Web technology that would mimic what they were designing in Metro for Windows 7 at the time with all those squares. Remember all those color blocks and squares and stuff? I think that's why Grid happened.

I don't think we should worry that time is going to get wasted on something that's not super useful to Web developers. I think the worry, and this is a really big worry, is that something will get rushed and put onto the Web without enough discussion. Maybe only one party's interests are being represented and not everybody's interests. And most dangerously, and this happens especially with DOM APIs and stuff that JavaScript can use that something about that technology might be insecure.

For example, contact API, like reaching in and grabbing all the addresses, phone numbers, home addresses, and email addresses from users, Web users' personal address book or some kind of payment system that uses credit cards, some kind of a login system, or password system. There are just a lot of things that we've seen end up being very insecure and ending up with certain companies grabbing, vacuuming up data or user data.

We just shouldn't ship that stuff onto the Web quickly. Speed is not the value that I think we should have there or that Mozilla thinks we should have there. We need to be careful about those things and do them well and not accidentally open up security vulnerabilities where corporations can abuse users or something crazy can go down. That stuff takes time. It takes time to think it through. It takes time to discuss it.

Chris: Specify and build, I'm sure. If we focused in on one, because I think both of you know little parts of this and I'm sure Dave, I, and our audience would be super interested to know, what's happening with this container queries thing? The only information we saw publicly was Brian Kardell's post that said, "Oh, maybe we can flip this idea on its head a little bit. Maybe we'll have a CSS function that has access to some kind of variable that represents the screen width. We'll use that to do what we pretty much could have done with a media query kind of thing," although maybe it's a little more verbose or something.

When you see that, I guess, Adam, just to split it up a little bit, have you been following that? Are you excited about that? Is that going to happen too fast or too slow?

Adam: Well, yeah, I've definitely been following it. I'm super excited about it. I've felt those pains many times. The current status that I know of, so just to quickly share its current state is that we're waiting for David Baron to release his proposal. We're going to get two proposals, one from Brian and one from--

Chris: That's Mozilla, right?

Adam: Yes. Yes?

Jen: Yeah.

Adam: Okay. What we're going to get is two competing proposals. Now, these proposals feel like they popped out of nowhere. I totally agree. It's like, "Hey, we've been asking and, magically, someone showed up in a poof of smoke and was like, 'Voila!'" We're all like, "Oh! Ooh?" You know?

The reality is, Brian has hacked on like way more than five versions of that - way more than five. He's connected with cats like Jonathan Neal. He's reached out to anybody. If you know EQCSS with Tommy Hodgins, he talks with Tommy all the time.

Brian has really connected himself to people who have been pushing this, got their ideas, had his proposal vetted, and then what happens is he'll take it to somebody like Tab or he just kind of shops it around. He shops his idea around and people are like, "Ooh, that still has cyclical issues," or, "Ooh, this has this issue."

When he showed someone that proposal that he released the other day, they went, "Hey, we could do that." That's when they were like [gasp], "Huzzah! All of our attempts, all of our efforts, all of this work that we've been doing for so long is finally going to pay off! Yay! I'm going to write an article about it."

Chris: It's funny that it's political in nature in that way. It's not like somebody tried to implement all five of those and found problems with it. They just had kind of a gut instinct of working on the project for so long that it probably isn't going to work. When that's voiced, that kind of becomes the rule of the land then, like, "I don't know. Somebody said that's not going to work, so we're not even going to try it." No?

Adam: No. I think you're right. When I started, I challenged it hard. I was like, "I want container queries. You need to tell me right now why it doesn't work." They were like, "Cyclical issues." I was like, "That sounds like B.S. Tell me the reality."

Chris: [Laughter]

Adam: [Laughter] They were like -- right? I was like -- so I did. I sat down with Tab for a long time.

Jen: [Laughter]

Adam: I was like, "Dude, I need to understand what you mean. It's over my head. Cyclical issues is over my head." He broke it down. As soon as I understood it I was like, "Oh, you're right. That is a foot gun. That is a gnarly foot gun. Okay, so--" and then I started to think about it. I'd think about it on my car rides home, but I don't have the time or mental capacity to sit there and hammer on it.

There are too many considerations and kudos to Brian and David for sitting down, synthesizing all of this, aggregating it, and contemplating on it, and proposing. The proposal is very admirable. I think the current state is a reflection of a collaboration of many, many intelligent people and it's really nice.

Chris: It's probably tasteful of Brian to say, "Hey, this is just an idea." I think he painted the picture pretty well, like, "This may not be the final thing." I don't know, this is just like, "I finally got a thumbs up that this could be doable," right?

Adam: Yeah.

Chris: What do you think, Jen? Have you gotten a sneak peek at what David is working on? What's your thoughts on all this?

Jen: What I've seen over the last couple years is that folks, especially influential Web designers, have articulated the need for container queries, element queries, or whatever you want to call it. People want a way to use something like a media query. But rather than say, "Depending on the size of the viewport," I want to depend on the size of the containing block.

When this card is in a column that's 200 pixels wide, I want it to do this. When it's in a column that's 400 pixels wide, I want it do that." Just for anyone listening who doesn't know what container queries means, that's what it is. Right?

Folks like yourself or Ethan Marcotte or there were a bunch of people who kind of articulated, like, this is what we need in order to write efficient code in the world of design systems. We need this. We need this. We need this. We need this.

It felt like it got to the place where designers and developers were kind of mad. They were like, "How come nobody understands how important this is? How come nobody understands that this is something we need?" which isn't really what was going on.

What was going on is exactly what Adam just described where the folks who understand how a rendering engine works, which I am not one of them, but who actually understand how paint happens, how page layout happens, when they heard about this request, they were like, "Oh, we get why that's important." I mean they invented media queries in the first place. They're the ones who came up with media queries. They know why a container query would be needed. They just were in their head going, "Uh… Yeah, that's not going to work." Right? [Laughter]

Because, yeah, if you say, "Oh, this card, I want this layout if the containing block is 400 pixels wide." But then once that layout is triggered, then the containing block size gets changed to 300. Then it's like, "Oh, wait. Go back and do the other layout." Then, "Oh…" you could easily end up in an infinite loop.

Then the question becomes, well, how do you prevent infinite loops? There are a lot of things in CSS where it seems like, "Oh, well, you just restrict the ability to use that and it'll be easy." But the truth is that, no, restricting the ability to use things is not a good solution. We rarely do that in CSS. You can kind of use everything with everything in CSS. If you do decide to do that when you get in there, you're like, "Oh, this is actually really way harder."

Chris: You know the one I always think of is just hover. You can change the width of something on hover and then it does….

Adam: That's what I said to Tab, too. [Laughter]

Chris: Yeah, it's like the most cyclical problem ever, but I've heard that they say, "Well, just because that one is messy doesn't mean we ever want to deal with messiness again." You know.

Jen: Right and it's one thing to have one object resize on hover. It's a different thing to have the entire page and the entire layout have multiple infinite loops happening all at once. You could easily crash the browser with that kind of stuff, I would guess. [Laughter]

Chris: Sure.

Jen: Not knowing how page layout works. But the CSS working group listens and we know how important this is. We've seen and it's helpful that authors have been demanding it. We've seen survey after survey, tweet poll after tweet poll of people being like, "Container queries. What we do we want? We want container queries. When do we want it? We want it now." [Laughter]

Yeah so, at Mozilla, we sit down periodically and think about what is it that -- I mean like any company, "What are our plans for next quarter? What are our plans for the next year?" We've increasingly, over the last two or three years, those plans are made knowing what authors want, saying, "What do people who make websites need the most? Let's see if we can knock a couple of those things off the list," which is why we're working on aspect ratios. It's why we're working on -- that's why we shipped Subgrid way before anybody else shipped Subgrid because we know that these are really important things to authors.

Container queries has been on the top of that list for quite a while. We sat down and said, "Yeah, we're going to make sure that this happens in first quarter 2020," and David Baron carved out a bunch of his time. He's one of the smartest people in the world when it comes to knowing CSS. People have said, and I think it's probably true, that he could probably recite the CSS2 specification from memory, he knows it so well. He also understands the Gecko rendering engine very, very deeply.

He's a distinguished engineer at Mozilla, one of the highest level engineers involved with layout and paint, if not the highest level. And so, he's spending a bunch of his time this quarter sitting down, going through it, being like, "Okay. What would this take? What could we do? Where are the limits?" Instead of just the first sense that it's not going to be possible, to be like, "Okay, but could it be? How could it be possible? How could we limit it? How could we structure it so that it…?"

Chris: Okay, you look at this, the process that's happened with container queries and be like, "This is actually pretty healthy. This is about as good as it can go." Yeah? Is that fair to say?

Jen: Yeah, I think so. There's been a lot of input from authors. Like Adam said, Brian Kardell from Igalia, he works over at Igalia, who is a company that implemented Grid on behalf of Bloomberg and put it into the Blink rendering engine and the WebKit rendering engine. They've worked on a bunch of other Web standards, implementing Web standards. They're deeply involved. Even though they don't have a browser, they're involved with making browsers.

Brian has been also looking at this and digging into it. That's how it works. Kick around ideas. That's how we ended up with Grid too is that there was a whole spec that got kicked around for years and failed, the template layout spec. Then there was a new spec that Microsoft put together and kicked around for a while. Then those two specs were merged. Those merged ideas were kicked around for a while. It took forever. It took too long, but then we ended up with something that was actually really powerful, really modern, and exactly what we need for sort of post-responsive Web design.

I think that that's going to happen with container queries as well. Container queries are probably not as complicated as Grid, but the conversation about, like, how could we make this happen with the rendering engine and not have multiple paints to the page and make it fast, make it robust, and make it not crash the browser?

Chris: Let's round-robin this one a little bit. Adam, do you feel good about the process that you've seen so far for container queries or have any other insight about how it's happening?

Adam: I mean I'm happy with its current state. I can't help but say that I wish things had happened faster and that more folks felt that they could contribute. There seems to be a handful of people that feel smart enough to prototype stuff or they feel -- and yeah, I think that that is a little sad. I wish that there were more competing proposals. It sounds like fun if you're interested in this sort of thing.

The proposal is kind of innocent and I wish it didn't have so much kind of pressure around it or anxiety. It would be way more fun if more people felt that they could contribute and if it was centralized more and it was easier to understand. But like Dave was saying in 399, you look at some of these proposals for declarative Shadow DOM, and you're 15 comments into the thread. Your mind is exploding.

There are barriers to entry that I wish would get knocked down. I don't know how to knock them down but, I think, overall, though, yeah, I'd give container queries a B+ in terms of, like-- [Laughter]

[Laughter]

Adam: This is pretty good.

Chris: Yeah. Yeah.

Adam: The outcome is going to be optimal. The flow seems good. I like that there's at least more than one person that's hammering on it. No, it seems nice. Although, I would love to see WebKit step in, though, yeah.

Chris: It does have a lot of implications. We've had -- you know we talked about the contact picker API, which I know actually nothing about, but it was just kind of a nice stand-in for a feature. It feels a little greenfield-y right? Which is, like, maybe that's why it's easier to move fast on stuff like that is there's nothing to break. It's just totally new, so you can just do whatever you want, in a way.

Jen: Well--

Adam: Isolate it.

Jen: I don't know that I would agree with that.

Chris: [Laughter] Okay.

Jen: I don't know what I want to say about it, but--

Chris: I get the privacy implication. That seems important, but I don't know. It seems like there's less to break when it doesn't exist yet, but feel free to think about it for a minute.

I want to ask Dave, though. If you're going to give it an A through F or whatever, how do you feel as an author about all this container query stuff?

Dave: Yeah, I mean I've been on the groups and whatever since the idea first came up. I helped Tayzon Matonich (phonetic) prototype something for Microsoft back in 2012. He wrote a blog post for Smashing about it. Quite literally, I've been thinking about this since 2012. There's a blog post from 2011. That feels astronomically long in Web time, you know.

Adam: [Laughter]

Dave: We still don't have it. We have a switch statement kind of on deck, you know. Which is cool. I'm into it. But, like, we're coming up on nine years of talking about it.

Chris: A little slow. Right.

Dave: We have a switch statement.

Adam: Yeah.

Chris: Yeah.

Dave: So, a little slow for me [laughter] as Dave Rupert, website maker. But you know, it's that thing; you take what you can get whenever it comes. But I guess I'd be curious about ideas to make this faster. I know the main element is just a spicy div, but that took ten years. [Laughter] How do we make it go a little bit faster?

Then even on top of that, let's say we come up with a thing. Now we have to wait for it to roll out. We talked about, like WebKit has sped up their cycles, their release cycles, and they have technical previews, but I'm looking at the WebKit feature status board right now and there are only 16 issues in development or in preview. It's like, cool, 2020, at most, currently, it looks like I'm getting three new features on the Web platform in 2020, here. Then there are a bunch that are in development.

I guess even if we solve the speed thing, how do we get browsers to move along with us? Even if we come up with a container query spec, how do we get browsers to move along with us? I'd love to know that answer.

Chris: Is it interesting that the browsers are--? What we did as authors was we asked browsers because it seemed like they were the people that can yay or nay this thing. We didn't ask the CSS working group, right? The CSS working group is just going to be like, "Oh, it looks like a nice syntax. We should have that." I don't know if that's how it works.

Dave: Well -- well -- [Laughter] I mean, we did ask. We solicited feedback on proposals and stuff. I think we always got sort of the can got kicked down the road. It was, "Oh, oh, well, well, we're working on containment. Wait until containment comes out."

It's like, okay. Wait two years. Containment is out. "Oh, oh, oh, oh, we're working on resize observer. When that comes out, we'll see."

Okay. Two years, resize observer is in Safari preview right now; another work done by Igalia. [Laughter] But it's just kind of this thing. it's like, man, well, okay. I guess we'll just wait and see if this happens again. I'll wait another two-year cycle and, hopefully, I have something I can use. You know?

Chris: I just wanted to an interesting loop on that but, yeah, Adam, what were you going to say? Prolyfills?

Adam: Prolyfills, yes. So, the idea here is, like, the foldable spec is kind of making one, but you can look these up. There are historical references where people are like, "This might be the Polyfill that batches the standard, but it's probably not. So, you can use it now to prototype with this future thing-y, spec, idea, whether it's HTML, CSS, or JavaScript. We're writing JavaScript to simulate what the browser will eventually do, maybe, if the spec doesn't change or if this proposal does go through."

Prolyfills can be a fun way to try these things out. There's a Typed OM Prolyfill. Yeah, the Foldables Prolyfill, these are -- I don't know -- they're fun, interesting. You can move fast with JavaScript and iterate your way towards stability.

Chris: Isn't the entirety of Babble is a Prolyfill, in a way?

Adam: I guess so. Yeah, I guess if you're using stage zero, like some really experimental stuff, that might be Prolyfill territory.

Chris: By the time it bumps up a little bit, it's not then a Polyfill. That's the word we're used to is a Polyfill, right? Which means this is actually supported in some browsers but not others, so this piece of JavaScript makes it work in all browsers. But by the time it's a Polyfill, it better as heck be -- you better be Polyfilling something real, right?

Adam: Yeah.

Chris: Prolyfill is just a clever word to be like, this -- you know, a little extra -- you know, be extra careful here because it might not actually be like this.

Adam: Yep.

Chris: Yeah.

[Banjo music starts]

Chris Enns: This episode of ShopTalk Show is brought to you by Clubhouse. Clubhouse is a fast and enjoyable project management platform that breaks down silos and brings teams together to ship value, not features. Let's face it. Slow, confusing UX is so last decade. Clubhouse is lightning fast, built for today's software teams with only the features and best practices you need to succeed and nothing more.

Here are a few highlights about Clubhouse. Flexible workflows: You can easily customize workflow states for teams or projects of any size. Advanced filtering: You can quickly filter by project or team to see how everything is progressing. There's sprint planning. Set your weekly priorities with iterations and let Clubhouse run the schedule for you.

It also integrates with the tools you love. Clubhouse ties into your existing tools, services, and workflow. Get notifications or create a story in Slack, update the status of a story with a pull request, preview designs from Figma links, or build your own integration with the Clubhouse API and more. It also has enjoyable collaboration, easy drag and drop UI, dark mode, emoji reactions, and more. When you're doing your best work and your team is clicking, life is good.

Clubhouse has recently made all core features completely free for teams with up to ten users and they're offering listeners of ShopTalk Show two free months on any paid plan with unlimited users and access to premium features. You can give it a try at clubhouse.io/shoptalk. Thanks again to Clubhouse for sponsoring this episode of ShopTalk Show.

[Banjo music stops]

Chris: Oh, fascinating. We knew container queries because it's been such a hot topic. But while we have people from browsers here, I think loosely a goal for the show is to be like, what's important to the browsers where you work? Is there stuff coming that we should know about or that you can just kind of leak here on this show because we're a reputable journalist? [Laughter] This is an opportunity….

Jen: Um, can I--?

Chris: Yeah?

Jen: I just want to--

Chris: Yeah.

Jen: One last thing about the container queries thing before we….

Chris: Please. Yeah. Yeah.

Jen: No, I was just going to say that I agree with everything Dave Rupert just said. Nine years is too long. I know I was being very optimistic in my first explaining of everything, which I stand by, but then also, yeah, I have another pessimistic view of it too. I do think that there are, especially when the answer -- personally, it bugs the crap out of me when people need something from CSS and the answer that kind of comes back in response is, "Well, you can just throw JavaScript at that instead." [Laughter] There are a lot of different variations of that.

Dave: Yeah.

Jen: But being like, "Yeah, resizers rule, we'll fix that for you," or something. It's like, "No. We need -- some of these things, we really need an elegant, serious, powerful solution in CSS itself." Why do we need that? Because not everybody has a 50-person, multimillion-dollar team working on their website. They need to be able to build a $5,000 website for their client. Writing a whole bunch of JavaScript in order to accomplish something is just not cool. We need -- so, I don't know. I guess all that is to say--

Dave: Yeah. No, I mean I think -- yeah. No, and that's sort of how I feel. It's like I want the tool. I want new tools. That's what I care about. Maybe this gets into the next question of, like, what are you all working on? What new tools do I get?

I just want more tools. Some stuff, you can Polyfill and Prolyfill and maybe Houdini will make that easier too, but some stuff like Calc, you can't really Polyfill. Var, you can't really Polyfill. Switch would probably be another thing you can't really Polyfill that easily, based on my weird -- [Laughter] Whatever.

Jen: [Laughter]

Dave: My kind of one-minute thinking.

Chris: I'm going to plus one that. It feels like JavaScript stuff is a lot easier. That's why Babble exists and why there isn't a Babble of CSS because a lot of this new stuff is just like, you can't really. It's just too low-level to do that. Not a media query for a folding…. I mean that seems a little Polyfillable, but there's some stuff that you just can't.

Adam: You just can't. Yeah, I hear that.

Chris: You just can't.

Adam: Tommy Hodgens is a good example, though, of someone who is like, "Oh, yeah? Tell me what else I can't do and then watch me do it." You know? [Laughter]

Chris: Yeah. True. Yeah, that EQCSS is pretty fancy.

Adam: But I agree with these sentiments. I would rather do things in CSS than write JavaScript. It's even sort of an issue I have with Houdini. I've been writing a ton of Houdini and I'm like, this is not really CSS. As an author of Houdini, it's JavaScript. As a consumer of Houdini, it's CSS-y. But I don't know. The story around Houdini is usually not the consumer side. It's usually the creation side. So, anyway, I'm on the same side. I would rather use CSS.

Chris: Hmm. Do you feel like Houdini is going to be just real quick, like there's going to be a package manager for Houdini, almost, where you're like, do you need this little thing in CSS?

Dave: NPM install torn paper.

Chris: Just install it.

[Laughter]

Chris: Yeah.

Adam: Hey, what about NPM install Masonry? I don't know. Right? You get, like, the….?

Dave: Yeah. Yeah, absolutely.

Adam: I think that, yeah, there should be an at Houdini namespace or maybe a package pops up that's a Houdini package. Yeah, or even, if we're talking about package managers, CSS kind of needs its own. It's sort of piggybacking on a really big, huge one, you know, NPM, and it's hard to navigate those waters sometimes. Anyway--

Chris: Well, what I want to know is where browsers are going or what they care about or just what's happening. Can we split the time here, towards the end of the show, between Adam and Jen here to find out? Tell us what your browser cares about and is working on and is up to, Jen.

Jen: One of the things I think that causes the frustration that things don't go faster is that much like any of the software that any of our listeners are building right now, this is also software and there are a limited number of engineers. There are a limited number of people who can design things or plan things. It just takes time.

Adam: Here-here. There are people behind these engineers. Sometimes Google sounds immortal. Chrome is immortal. It's like, uh, no, it's run by people and it's, in some ways, short-staffed. So, there's that reality, right?

Jen: Yeah, or you're like, "Oh, there are four people working on that." You're like, "What do you mean there are four people working? That's completely impossible. Aren't there 400 people working?" It's like, "No. No, there are like four," so each time we decide to do one thing, we're deciding to not do something else."

What are we working on right now? One of the things that Mozilla is working on is another layout model that's super popular that everybody keeps asking about is a Masonry layout, right? People keep using the JavaScript library to do Masonry. People have heard about Grid. They're like, "Oh, yeah. I get to finally do Masonry in CSS." It's like, "No. No, Grid doesn't do Masonry. Grid only does grid."

But one of the things that one of our engineers started working on is solving that use case. Mats Palmgren wrote a proposal and it's at the working group right now, the CSS working group, to figure out how to do Masonry in Grid.

Chris: Really?! It's not Display Masonry, is it? It's still Display Grid: grid, columns, Masonry?

Jen: Yeah, so he's prototyping an implementation that will go into Nightly behind a flag, I assume. It will not ship into the real world yet. It will just be a chance for us to play around with it and use it. Because the spec is not done and there's not an agreement about whether it should be Display Masonry or should it be Display Grid: grid, template, columns, Masonry. That's a thing. People who are listening could maybe jump in on the debate if you have opinions about that because that's a thing that has to get worked out.

There's an example, right? If we wanted to violate the Web standards process, we could, at Mozilla, just say, "Oh, we don't care about anybody else. We don't care about having a conversation. We're going to ship it. We decided by ourselves that we think it should be Display Grid--grid, template, columns, Masonry--and we're just going to ship it. Forget everybody else. Oh, it's shipped. Too late to change it. Can't change it because it's already shipped." That would be a real bad thing to do and it's something that Mozilla would never, never do.

Instead, we are having a conversation in the CSS working group and prototyping it in Nightly behind a flag so that people can play with it and check it out. See if they like it or not. But that's pretty exciting to me.

Chris: That process seems pretty well established, right? Kind of everybody is doing that. Yeah. Yeah.

Jen: In the CSS world, yeah. In the CSS world, yes. But in the JavaScript DOM API world, no. People are not doing that and it's a really alarming trend that's happening right now is browsers, a browser, in particular, seems to keep -- they just do what they want and ship it.

Chris: Okay, so we've got some new stuff. Masonry is a good one.

Jen: Masonry. Masonry. Printing, we're working on printing and cleaning up a lot of the bugs that we have in printing and fixing printing because printing has been neglected for so long. It's some of the oldest code, oldest technical debt sitting there.

Part of the reason that Mozilla, Firefox engineering, decided to work on printing is A) we care about printing but B) because doing so will put us into a really good position to be able to do other interesting things with fragmentation. Being able to do other interesting things with fragmentation is what's going to make it possible to do regions down the road or some sort of replacement for regions to have a way in which you can flow content from one column to another column or one screen to another screen now if folding screens turns out to be a thing. Or one page to another page if you are printing. It's kind of a big technical debt project to pay down technical debt, fix printing, and get ready for the next generation of layout ideas and graphic design ideas that might want to come after that.

Chris: Cool. Thanks for the insight there. That's nice to -- I don't know. That's fascinating to me for a variety of reasons. Adam, what's Google on? A big question, I know, but you had a list, I think.

Adam: I've got a list, yeah. I think it should start with, it's not just Google hacking on Chromium anymore. We have a really rad relationship going on with Microsoft. It is just thriving. We have Igalia, who contributes, we have Opera that contributes, and we have Samsung that contributes. These are the major players that contribute. It's just kind of interesting. A lot of these features aren't necessarily Google efforts and it's really nice.

I do want to tap a little bit on Layout NG. Layout NG, the engine that we inherited, was from the '90s and it had bugs. It also was starting to become debt, so we've been paying down our code debt. What we get with a lot of that is we get performance on lower-end devices. We get first-class support for multilanguage layout.

Bruce Lawson, the other day, was on a podcast. He's amazing. He goes, "Built-in beats bolt-on, Bigley," right? It's just this amazing phrase.

Dave: Oh, wow. [Laughter]

Adam: It's like, what we had was sort of like some concepts built onto the engine and they weren't built into it. What we're doing in this refactor is we're building the considerate internationalization in the beginning and so this also sets us up for additional refactors. We have another effort called Flex NG, which is Flex Next Generation, not Flex, not good.

[Laughter]

Adam: Next Generation Flex will come with Gap. Next Generation Flex will come with performance improvements and bug fixes. Hey, Jen, this one is for you. You know your bug that you have filed against Chromium for Flex and its direct descendants kind of stretching images? That will be fixed in Flex NG.

Jen: Yes! Yay!

Adam: Also, we have Layout NG coming out, which is like Grid NG. If you looked at a tweet from Microsoft recently, they said all the stuff that they're working on, which was fragmentation, tables, grid, Grid. What they didn't tell you was, Grid is quite generic, isn't it? What possibly could Microsoft be doing with Grid? Hmm. I wonder. Why don't you ask them? [Laughter]

Then Microsoft is also making SVG improvements and they're helping push forward fragmentation ideas. That's just sort of like Layout refactor stuff.

We also do something interesting called unshipping. Unshipping is, we spend a lot of time removing inherited WebKit bugs. These are things like WebKit margin collapse. We just released that or we're about to unship WebKit margin collapse.

We're also going to unship some aspects of WebKit appearance so that buttons can't look like radios. Did you know you could do that right now? Anyway, you could say, "Hey, button, appearance radio or radio appearance button." We're like, "Hey, that's not fair."

Chris: I hate it.

Adam: That's really tricky, so we're going to unship that.

Chris: [Laughter]

Adam: We're going to unship that. We're going to unship WebKit line clamp.

Dave: [Laughter] Wow! No rules.

Adam: No, hold on.

Chris: What? Line clamp?

Adam: No, line clamp will still be there, but check it out. Did you know that you can use percentage to line clamp? Line clamp 50%.

Chris: No.

Dave: Is that based on the height?

Adam: That's….

Chris: The height or what?

Adam: Exactly. It's based on the height of your container. Yeah.

Dave: Wow. Not like padding.

Chris: But does it have to have a fixed height to do that or can it be its natural height?

Adam: I can't remember, but there are all these weird little bugs around line clamp.

Chris: Oh, that's awkward.

Adam: I don't really feel line clamp is very useful right now. We're also adding right to left support for line clamp, so like these are fun, little refactors that we're doing, things we're removing.

We've also fixed over 100 bugs with tables.

Jen: Ah, yeah, tables. Ugh. [Laughter]

Adam: Right. Here's another fun thing about bug fixing and unshipping. There's this other side of it where Firefox has a bummer time where, if Chrome -- you know this is coming -- yeah, if you're a major browser shipper and you ship a bug, people might assume that that bug is the reality.

Jen: Yeah.

Adam: And so, Firefox has to go build the bug into their engine.

Jen: Yep.

Adam: That sucks. That sucks really bad. What we do is, every bug we fix, we could go tell Firefox, "Look. Don't build that anymore. We've resolved it." It sort of removes the work off of multiple plates. I think that's really cool.

Some other fun things that we're working on, we have Web fonts. Optional font display is getting worked on. We have loading performance that's been getting worked on. Layout NG comes out with a bunch of stuff.

Anyway, yeah, ask questions. Cool.

Chris: [Laughter]

Dave: Oh, you said font stuff. Is dev tools going to get font tools like Firefox's font tools?

Adam: Yes! I don't know if you know. Chrome dev tools lost many engineers to Microsoft.

Dave: Ah.

Adam: We've refilled. We have new teams. They're ramping up into the ten-year-old, you know, ten-plus-year-old, very complex tool known as dev tools. We have folks ramping up and we have UX designers on it now.

We're committed to making dev tools better. We like the authoring experience. And so, anyway, I'm very involved with them. We have Grid stuff getting worked on. We have font stuff. Anyway, we have lots of plans there but it is difficult for us to move quickly in that space since we don't have any seasoned engineers in there.

But yes, it's on our plate. We love that stuff. Dev tools is a huge tool. Anyway, so I have lots of thoughts on that too.

Dave: Yeah. Sorry. I'd love to hear more, but yeah. Sorry to interrupt.

Adam: Yeah, no worries. Other stuff with Layout NG, now there's content editable improvements for all languages, complex languages. They used to have expensive, like perf and layout costs. But we've put those all down so, like, if you're in another country on a low-end device, we're saving your battery. We're saving all sorts of stuff. It's kind of cool.

We have new fragmentation support coming out for multicolumn. What this does is, we're kind of ditching the old one and refactoring into a new one that leans towards us being able to implement something regions-like. Like multicolumn, for example, if you put a Flexbox layout inside of a column, it is really buggy. We have perf suggestions. We have suggestion break avoidance, so you can define where the page breaks and how these things flow.

Chris: Columns as regions is blowing my mind a little bit.

Adam: Right? It's kind of the first regions thing we've ever had.

Chris: I'm going to need a demo on that.

Adam: You're spanning multiple fragments. We have Typed OM stuff coming out, like the app property is coming out so that you could define your custom property in CSS and you don't have to use Houdini and JavaScript to do that.

Let's see. What else do we got in here? We have scope styles just got a proposal together the other day, not to be confused with Shadow DOM. This just got revitalized.

Chris: What?!

Adam: Someone is pouring water on it. They're like, "This isn't dead. You shouldn't have to do Shadow DOM to scope a style," so that's got new life. Declarative Shadow DOM has new life.

Chris: Huge.

Adam: We have dedicated people….

Dave: Somebody listens to the podcast. [Laughter]

[Laughter]

Adam: Oh, man. We have new math and malfunctions coming out, so Igalia is -- dude, Igalia rules. I just want a real quick shoutout to Igalia. You all are awesome! Seriously, these cats are so cool. They're wicked smart and they just sort of contribute to every browser. They're just out there contributing.

Google spends a lot of money to help Igalia even implement features in other browsers. It's really cool. The amount of sharing that actually goes on amongst the browsers has been really illuminating. The more I learn about how well we're collaborating with Microsoft and then even the ways that we collaborate with the other browsers.

It's so funny. I don't think our engines compete. I just want to really quickly bring this back. I don't think our engines compete. All our engines want the same thing. We all want to be the platform. But our browsers compete, and that's kind of cool. Right? We have Brave and -- anyway, so that was just a weird little side note.

Always, aspect ratio is on the docket. Let's see. Was there anything else I missed in here? We are all over. You just saw our HTML elements refresh.

Chris: I know we're kind of over, unfortunately, because we didn't get to -- scoped styles would be amazing, but they made me think of Jen and Miriam talking about all this origin stuff. We didn't even get to that. We're probably going to have to save it, unfortunately.

Adam: Oh….

Jen: Yeah, oh, gosh. Adam, you did such a good job of doing your homework, too. There's a long list of whatever Firefox is working on. I just don't -- I just didn't bring it with me. I didn't do my homework. [Laughter]

Dave: I look forward to reading your blog post.

Chris: That's okay.

Jen: People may have noticed a lot of overlapping like fragmentation or aspect ratios or whatever. It's because a lot of these things are happening in the CSS working group. They're things that the working group itself have been working on or that we do collaborate, as Adam said.

The first time I ever met some folks from Microsoft and Adobe who are on the CSS working group, I went to a workshop that Elika Etemad held in Seattle to bring a bunch of folks together to read the Flexbox specification to each other and to help -- yeah, to user test the Flexbox spec. It was cool and I met Greg Whitworth and Adam Stern and some other folks. Other people in the room who don't work for browser vendors were like, "Ooh, the folks at that table," because I was sitting at their table, they were like, "Ooh, they're going to start punching each other. They're fighting. Because they're from different browsers, they must fight each other all the time."

I remember being like, "Wait. What?" And realizing, especially now, years later, that Adam and I have more in common. We have the same job as each other when, like, no one else at our companies have this job. [Laughter] In some ways, we're more akin and more aligned and more likely to collaborate with each other than perhaps even other folks inside.

Adam: Ah. I agree, Jen. You're awesome.

Jen: It's so true because, what do we want? We want to make something really great for the Web. We want a really great solution to regions to make overflow fragmentation or whatever it is. We want aspect ratios because we want you all to have an aspect ratio property.

Yeah, there's a lot of synergy there and a lot of overlap and a lot of working on the same things together.

One of the things about the CSS working group right now, what the working group is working on is line-level stuff. For a long time, the working group had to fix and finish CSS2. Then they finally got to a place where they could work on easy stuff like border-radius and all the stuff that went into CSS3. When that was done, they could start working on big layout models, which is why we got Flexbox and Grid.

Now that they've done some of those bigger block-level or giant block like container level layout modes and stuff, they've moved on to look at line-level stuff. To try to fix line-height, which is a nightmare, to try to come up with better line layout, especially for the wide range of languages that are out in the world. Clean up a lot of the technical debt that got created when CSS2 was created and line-level stuff was sort of weird. A year, two years, or four years from now, you're going to start to see a lot of adjustments to what happens with inline boxes and line-level kinds of things.

Dave: Oh, interesting.

Chris: That's awesome to know. We're a little over, so we've got to wrap it up. Thanks so much for being on.

Dave: We did it.

Chris: 400 episodes!

Jen: Yay!

Chris: Woo-hoo!

Adam: Woo-hoo!

Dave: All right. Thank you all so much for coming on Episode 400. We really appreciate it. Very special, especially for me. I love learning about this stuff and looking forward to when Chris and I buy our way onto the CSS working group.

Jen: [Laughter]

Dave: That's our heist, 2020 heist, 400 series heist.

Chris: I'm going to bring rice crispy treats in two different pans.

Dave: Yeah.

Chris: They're going to be distributed evenly amongst different -- it's like a fragmentation joke. They're going to be like, "Oh, you're so smart."

Dave: But I guess before we go, how can people follow you and, I guess, download your browser or give you money? We'll start with Jen.

Jen: Twitter, @JenSimmons, JenSimmons.com.

Dave: And an excellent YouTube channel. Oh, my gosh.

Jen: Yeah, Layout Land, the YouTube channel, which I really hope to be able to get to make videos for us soon. Meanwhile, I made some videos on a Mozilla developer YouTube channel along with Miriam Suzanne and a couple other people. Use Firefox! That's the message.

Chris: Sounds good.

Jen: Use Firefox!

Dave: Use Firefox.

[Laughter]

Dave: Great job.

Jen: That's how you give us money. Use it. Use it. Get your friends to use it. Test your websites. Make sure your websites work in Firefox so that we have more than one rendering engine, so that we can have a Web standards process. There can be more than one point of view in figuring out what it is that we should have on the Web.

Dave: Awesome. Thank you, Jen. Adam, how can people follow you, give you money, and download your browser?

Adam: Yeah. I second Firefox rules. Go download Firefox. The dev tools are sick. You can follow me on Twitter, @argileink. You can find me on GitHub at ArgileInk. That's plenty.

Here's mine. Go write Web platform tests, y'all. That's the best way you can help contribute. Anyway, loved this show. Thanks for having me on.

Dave: Oh, little did Adam know every single website I make is a platform test because it is perfectly coded in every way.

[Laughter]

Adam: Touche. Wow. That's actually a really good reply.

Jen: Reduce test case. Reduce test case tests.

Dave: Yeah.

Adam: [Laughter]

Chris: Yeah.

Dave: Yes, well--

[Laughter]

Chris: I only do maximize test cases.

Dave: [Laughter] Thank you, ShopTalk listener, for downloading this.

Chris: We've gotta go.

Dave: Listening all the way to Episode 400. We really appreciate it. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you, maybe like this company.

Chris: Hey, ShopTalk Show friends. Are you looking for a job, because we got a job to tell you about? It's just for a straight-up front-end engineer. The place is called SDG and it's in Los Angeles, California. A nice place to be here. They're looking for somebody with two to three years' experience, HTML, SCSS, JavaScript, Gulp, Webpack - the kind of stuff we talk about on the show, of course. Experience with modern frameworks is great: Vue, React, headless implementation is nice, like using a headless CMS like Contentful to build stuff.

It looks like they do a lot of e-commerce stuff and complex Web applications. Again, it's in LA. The place is called SDG and they're looking for passionate people. They're a tightknit crew. They don't offshore anything, so it's all kind of internal work. It's a great engineering company, so check it out. Make your six-figure salary. Go get it.

Dave: Chris, do you have anything else you'd like to say?

Chris: Ooh… ShopTalkShop.com.