Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I am Dave Auto-Fill Rupert and with me is Chris 1FR Coyier. Hey, Chris. How are you?

Chris Coyier: [Laughter] I'm doing fantastic. We have a special guest this week on the show, been on the show multiple times, a friend of the show, let's say, and one of my favorite people on the Internet and real life, Jen Simmons. Hey, Jen. How are you?

Jen Simmons: Hello! I'm very excited to be back. Super excited.

Chris: Yeah.

Jen: Thank you for having me back.

Dave: Whoo!

Chris: Oh, it's my pleasure. Jen, you're perfect for the show, of course, because of your long experience with front-end design and development. Just are now at Mozilla and affecting the future of browsers, how they work, and how our fancy world of front-end development works.

Most recently, you had a huge launch with a new YouTube channel with yourself, but a bunch of other voices and personalities talking and teaching about front-end development. Maybe we'll just start there because people should know about it, I think.

Jen: Yeah. Yeah, Miriam Suzanne, Deja Hodge, and I are making videos. We're the people on camera and writing the content.

Chris: Mm-hmm.

Jen: Then Jay Dedman and Ryan Hodgson are behind the scenes doing producing, editing, and making everything happen.

Chris: What's it called? Does it have a name?

Jen: Yeah, so if you go to YouTube.com/MozillaDeveloper, it's just sort of Mozilla Developer is the overall name of the channel.

Chris: Okay.

Jen: Yeah, and it's easiest maybe just to type that in, YouTube.com/MozillaDeveloper to get to it, or you could search. Although, as of last week, because the channel was so new, it wasn't really showing up in search results yet when you search for Mozilla Developer, so you might have to scroll a bit or poke around a little bit more.

Yeah, it's exciting. It was a long time in planning to really find a way to make the kind of content I was making on the Layout Land YouTube channel, to make it with more people and to broaden out the topics instead of just talking about graphic design and CSS for layout, to talk about all kinds of things from accessibility and dev tools to, like, why is the Web the way it is? Are we annoyed by that? Should we want to change it?

Chris: [Laughter]

Jen: Is it good? How do you make a website work in every browser? What's going on with all this tracking protection stuff? What does that mean for your ad sales team?

Dave: Yeah. Wow.

Chris: You'd think with so many videos and stuff out there on the Web, you'd think, "So, more?" You'd think somebody would be doing this, but they're kind of not, at least not to this quality level with this same kind of spirit. You're not trying to train a beginner developer or anything. You just want to talk about what's going on.

Jen: Yeah. Thanks.

Dave: I like Miriam's video about--

Chris: [Laughter] The weird one?

Dave: --unset and reset.

Chris: Oh, revert.

Jen: Oh, yeah.

Dave: Weird was also very good. List of shame; we haven't had Miriam on the show. Somebody pointed that out and we were like, "Are you kidding me?" I was like, "No, way." Anyway, list of shame. We'll get her on.

It was all unset and just the weirdness of it. It was like, yeah, that is actually kind of weird and not how you want it. Then there's all reset, which showed up in Firefox.

Chris: Can we just steal her thunder? I actually don't totally fully understand it all the way. Should we do a ShopTalk Show version of that? What is reset or revert? I don't even know.

Dave: Revert.

Jen: Yeah, it's call revert. Yeah, people should watch the video. It's funny because, on the one hand, I'm the person who watches the videos and makes sure that they're cool and approves them. On the other hand, I'm like the audience and I was like, "Wait. What? Huh? What?"

Chris: [Laughter]

Jen: I watched it like four times and I was like, "Oh!" Yeah, so there are several different CSS properties that you might think would kind of be an undo. I don't know. You have a paragraph style that you set universally and then, for a very specific cart, you want to kind of like undo the universal style and go back to the user agent styles. Maybe on a particular paragraph, you just want to--

Chris: There's initial? Isn't that initial, though, or is it not?

Jen: Yeah, there's one called initial. There's one called -- I don't know. I don't remember off the top of my head. There are three or four different options. She walks through them and shows you. You might think that this is going to undo the UA style for paragraph but it won't.

Chris: Ahh.

Jen: What this is going to do is it's going to, for example, the display property she shows where it's easy enough to use some of those older values. It's easy to use some of the older values in order to remove color or to remove margin but if you try to say, "Display," and you go back with those older values, you actually end up at, well, what is the original display? By default, display is inline.

Chris: Yeah, display is terrible because it's overloaded, right? It also involves none or not and so, if it's none, it doesn't know what it was before it was none.

Jen: In her video, she'll give an example of, you might want to -- what's the default display on paragraph? Well, the default display on paragraph is display block. How do you get to that? A lot of the other options would go back to display inline and stuff.

Chris: Mm-hmm.

Jen: She explains why. It's hard to explain on a podcast.

Chris: Yeah.

Jen: Reset is the newer property that's come out most recently that she explains, like, oh, most of the time probably what you want is reset. You say, display reset. I'm sorry, revert. See, I got it wrong.

Chris: Revert. Yeah. [Laughter]

Dave: Revert.

Jen: Display revert.

Dave: Yeah, sorry, I got it wrong.

Jen: Yeah.

Dave: And I made you get it wrong.

Jen: Revert. Yeah, yeah, yeah. So, it's nerdy. It's like a high-end nerdy thing that's actually really kind of practical and helpful. That's the idea with the channel is that we're not -- sometimes people get a little confused and they're like, "Oh, you're trying to compete with Lynda.com." It's like, no, no, no, no, no.

Like, "Oh, you're trying to do what MDN Web Docs does, which is document everything about the entire Internet and Web technology on video." It's like, no, no, no, no, no. We would need television studios on top of television studios to do that.

[Laughter]

Jen: What we're trying to do is really help with the most pressing problems right now. What's really frustrating right now? What new things shipped in browsers? Not that we're covering everything new that's much better done in text, that's much better done in, like, what's new in Firefox whatever; what's new in Chrome whatever? Like press release kind of blog posts.

But the kind of like, "Oh, everything is about to change about underline styling. I as a front-end developer or as a Web designer, want to know what's going on with underline styling, but I don't really have time to read the specs, to read 14 blog posts, or to dig into all these Web docs. Can somebody just take eight minutes and explain it to me so I get the higher-level understanding of what's changed about underline styling?

Cool. Okay. Here's a video that does that. Then once you kind of get that big-picture understanding in your head, later you can go look up Web docs or later you can go to other resources to find details and stuff.

Dave: Didn't you just put up a video about the variable fonts inspector in Firefox that is killer?

Jen: Thanks. Yeah.

Dave: I think people probably aren't even on the variable fonts train.

Jen: Right.

Dave: But then you see this and you're like, oh, this browser has sliders that just make it really easy to understand what's going on. That's amazing.

Jen: Yeah.

Dave: Usually, it's like, oh, you want to set slant to either zero, one, or 4,000.

[Laughter]

Dave: That's how you make…. That tool is almost, I think, going to be indispensable for variable font workflows in the coming future.

Jen: Yeah. We shipped a completely new font editor in the Firefox release when we shipped variable fonts, which I think was last fall, like a year ago.

Dave: Mm-hmm.

Jen: Variable fonts are still new and people don't really know about them. Somehow, I think people didn't really -- some people were super excited about the font editor, but I think a lot of people just didn't know that it's there.

Dave: Mm-hmm.

Jen: I guess we don't really spend a lot of time clicking on random buttons inside dev tools to see what might be new. That's part of the videos. They're sort of one of the series. There are several series, and one of the series is kind of like, "Hey, let's show you the most useful developer tools in Firefox that you might not know about. Let's give you a tour of the grid inspector. Let's show you the font editor with the variable font tools. Let's show you."

It's funny because one of the first ones I did was about the screenshot tool. I've never really used the screenshot tool in Firefox. Suddenly, everyone on my team, everyone on the video team was like, "Uh, this the most useful thing ever," and we're all using the heck out of it. [Laughter] It's so funny.

Dave: [Laughter]

Jen: It's funny how much you learn while you're getting ready to teach something.

Dave: Oh, if you're making videos, sometimes you have to put screenshots of websites in videos.

Jen: Yeah.

Dave: Now you have a really easy way to do it. Anyway, yeah.

Chris: I had to obsess about this revert thing for a minute. I think I get it now. It's that unset would remove even the user agent styles.

Jen: Yeah. Yeah.

Chris: But revert leaves the user agent styles. Uh, okay.

Jen: Yeah.

Chris: That's awesome. Got it. Cool.

Jen: Revert goes back to the default that the user agent style sheet is using--

Chris: Right.

Jen: --for that particular element that you have where the other ones are, like, what is the inherent original thing that this property--

Chris: Yeah.

Jen: --wants to be, completely independent from elements in the specification.

Chris: Incredibly useful. Very glad that that exists. I have another question about this type of thing now. I've been in, just recently, a couple of not arguments but big long discussions about browsers and what they're allowed to ship, what's responsible to ship, and things like that.

If the marketing behind revert is like, "Firefox ships revert," the first thing a developer might think is, like, okay--

Jen: Is it in Chrome?

Chris: Well, "Is it in Chrome?" but is it spec'd? Did Firefox just go rouge and just invent some new property to ship?

Dave: Moz revert.

Chris: Firefox never does that, so I would think so. Don't assume that that's happening. It's kind of like, who else has this? What's the most responsible way to ship something like that? In this case, I'm looking around and it looks like, well, it's a part of the CSS … spec, which is candidate recommendation, so I guess it kind of is.

Jen: Yeah.

Chris: Although, this says -- I don't know. Can we talk about that for a minute?

Jen: Yes. Let's talk about that, your hot topics. You go straight for the jugular.

[Laughter]

Jen: That's a really good question and I think that that's one of the things that I have had a chance to kind of learn a lot about and get a lot of insight into being at a browser maker when I never did as a Web developer. All of the different companies that make browsers are run by people. Those people have different opinions about the answer to that question. Those companies, each company has its own culture around that.

Chris: Mm-hmm.

Jen: The answer is, the correct way, the way that the Web standards culture, the way it's supposed to work is that whatever new technology, new ideas that people have about what they want to put into browsers should get written in the specification. It should go into the JavaScript specification, the HTML specification, the CSS specification, or into one of the other many, many, many other kind of API specifications that exist. Some of them are W3C. Some of them are WHATWG. Some of them are--

Chris: What if it's just an idea, though? Still, put it in--?

Jen: Well, the idea, it's fine if a browser maker wants to kind of, behind the scenes, behind a flag, iterate on a few ideas.

Chris: Mm-hmm. Sure.

Jen: Just drop some code in their browser and test out some sort of idea. That's totally fine.

Chris: That feels right to me, too, because it will never -- users don't mess with flags ever, ever.

Jen: Right. Right.

Chris: Unlike a vendor prefix, which developers use and then, uh-oh.

Jen: Which didn't work. That was terrible. Not dependable.

Chris: Very terrible. In a sense, I don't care what you do behind a flag. Do whatever you want, literally anything.

Jen: But the idea with that, each browser team needs to have a conversation about that, though, because they don't want to throw a whole bunch of code that's sort of hanging out behind the scenes in their piece of software. Anyone who builds software, you don't want to have a lot of extra code that's not doing anything, cluttering up the downloads and stuff, like sitting around for years and nobody knows anything about. There is a way in which, if you're going to do some experiments, your own team needs to figure out when is that okay and when should they come out if they fail, or whatever.

Chris: Okay.

Jen: But the idea is that you shouldn't ever, ever ship something in a browser, actually ship it without the flag unless it's been specified, unless it's gone through a specification process. That specification process is not one browser maker dropping off some document and being like, "Hey, we wrote a spec. Bye. Byeee! We're shipping it tomorrow. See ya!"

Chris: Yeah.

Jen: There's supposed to be a process where multiple browser makers get together and discuss it. Then this company says, "Hey, this is really important to us. These are our values. We've expressed these values in the spec. We definitely want to ship this."

Another browser maker can come along and say, "That's actually opposite of our values and we're never going to ship that. We're not okay with that. we need to talk about this."

Those two browser makers, three browser makers, or five browser makers will get together, people who actually aren't browser makers but are companies that matter and are part of these working groups can discuss it and say, "Okay, let's come to a compromise. Let's come up with an agreement. Let's figure out something that actually works for everybody."

Every company has what they need or what they want to provide to the world but that we've worked it out. Then companies can start shipping. Then companies, once we've agreed and it's spec'd, will start to ship stuff.

Things are not supposed to be shipped until they've been spec'd and things are not supposed to just be an early draft of a spec. It's supposed to be a well discussed, agreed on spec.

I would have to say the CSS working group--and I've been a member of the CSS working for maybe around three years now--this totally happens. This is exactly how the CSS working group runs. You'll see Apple show up and say, "We object," or Microsoft, Mozilla, or Google show up and say, "We object to this. We have a problem with this." Basically, that means we're vetoing the other browser's ability to implement and ship the idea that they have. They can't do it. We disagree. We don't agree.

It doesn't happen very often. It's kind of rare to be that strong to throw down a veto. What usually happens is there's a refinement process. I know that sometimes people say trashing things about the working groups, how horrible it is, and how awful the experience is. My experience in the CSS working group has not been that it's horrible at all. People are actually really kind to each other. It's a really healthy conversation and the specs end up better.

Chris: Mm-hmm.

Jen: The specs end up better. They just do. Even though all of us, including myself sometimes, are like, "Can we just go faster? This is hard. I don't like talking to other humans." The truth is, okay, we spent a year talking about that and, wow, it's so much better than it would have been if we had just shipped the very first idea.

Chris: Even on a really small scale, I find that to be true, like at my own company. If somebody just goes and writes some code and ships it, it might be good but it's almost always, if not definitely always-always, better if we all talk about it and multiple people see it and bring their own experience to it. I can see that play out over and over.

Aren't there levels of specs? I know that there is, right? The final level being candidate recommendation. I have something stuck in my head where a spec can never reach that level unless there are implementations of it in browsers already. If there's massive disagreement, the spec can never get to that level, right?

Jen: Right. Candidate recommendation isn't the highest level. That's sort of the most, like, hey -- it's a candidate for recommendation, like, we think that this is pretty close.

Chris: Oh.

Jen: We think that this is pretty much done. You should definitely start implementing now. Now is a good time to implement browsers, but it has to go.

I think it's -- oh, I forget. I have to look this up. It goes from candidate recommendation to proposed recommendation, PR, and proposed recommendation means that it has been implemented already and we definitely think that this -- like, it's super pretty much done.

Chris: Right.

Jen: But then there's even one more level after that, which is an official recommendation.

Chris: Official recommendation. Okay.

Jen: It's just called, "Recommendation." Before candidate recommendation is working drafts. It goes from working draft to candidate recommendation to proposed recommendation to recommendation. This is the W3C process.

The CSS working group is part of the W3C and a lot of the other groups are, but a lot of the work is not part of the CSS -- I mean a lot of the other working groups are not part of the W3C. They're part of the TC39 working group or whatever the compliance, whatever.

Chris: The JavaScript one. [Laughter]

Jen: Yeah. Then HTML is not part of the W3C any more. It's the WHATWG working group or whatever.

Chris: Mm-hmm.

Jen: It's not a working group but I forget. I should know this better but I don't.

Chris: It's complicated, in other words.

Jen: It's so complicated. It's so complicated. It's so crazy complicated.

[Banjo music]

Chris Enns: This episode is brought to you by Backlog. Backlog is the all in one project and code management tool development teams have been waiting for. With project management, bug tracking, wikis, and get rolled into one easy to use platform, Backlog provides the powerful features development teams need under a clean UI that anyone can use.

Easily onboard your whole team and start working on tasks in minutes. Additional features like ANT and burndown charts make it easy to manage projects. Mobile apps keep your team connected, and their simple pricing scales with you, so you can stop worrying about per-user charges.

You can build your next project with Backlog. Get a 30-day obligation-free trial at Backlog.com/ShopTalk or follow the link in your show notes or your podcast player right now. Our thanks to Backlog for sponsoring this episode. Keep all your projects organized with Backlog.

[Banjo music]

Chris: Well, that's cool. If we tie it all the way back to revert, it's like, okay, not that many browsers have this now but it looks like Safari does, weirdly enough. Firefox does and Chrome doesn't, so whatever. Anybody is free to do this because the spec is in this kind of later stage of acceptability.

Now it's just a race, in a way. If Chrome doesn't have it, well, too bad. The spec is already agreed upon here. We're not going rogue. The spec is done, so we're implementing something that's already in the spec. If you don't have it, well, then just catch up.

In this case, we're pointing at Chrome doing that, but it's just as often or more often that it's Chrome shipping some crap and pointing at Firefox for not having it, right? It's a back and forth kind of thing. [Laughter]

Jen: Yeah, and the idea is that each spec would definitely be at a certain level. For instance, yesterday, we had a CSS working group meeting. We resolved on one, the last open issue for subgrid. Immediately, Elika said, "Okay, well, we just resolved the last issue for subgrid. Why don't we move, in the next week or two, to take the grid level two spec," which is the part of -- that's where subgrid lives, grid level two. Right now, I think that's a working draft and we're going to take it to candidate recommendation.

Firefox has already implemented it. It's behind a flag. Well, it's in Nightly. It's working in Nightly. I think it might even be in beta. We're thinking about shipping it. We're trying to figure out the timing of when exactly to ship it. We're testing it. We're making sure that there are no problems with it.

The fact that the CSS working group is going to take that spec to candidate recommendation right as we're about to ship is a really good part of the process. There are no open issues. The spec is pretty much done.

Chris: Mm-hmm.

Jen: We're implementing it. We're hoping that other browser makers will implement it. It doesn't always -- it's not always that nice, neat, and tidy. There are times when people have implemented stuff that's a working draft. There are times when things lounge around and stay in working draft longer than maybe they should.

That's why, really, the best thing is for people who are involved with implementing CSS or are on the CSS working group to just always be talking to each other, to always just be communicating, to always be like, "Yeah, we have this process, but the process isn't perfect," and so it's not about automating this process. It's about communicating and using this process to help us talk to each other.

Our engineer Matt is implementing subgrid. He had questions about how to do it. Rather than Matt just going off and making up stuff by himself and being like, "Well, I think it should be like this. That's how I'm going to do it. I'm not going to talk to anybody. I'm just going to do it and ship it."

That's how CSS used to get implemented in the days of CSS2 is like each company would just kind of do their own interpretation of the spec and it turns out that didn't really work. That's why we had all those bugs in IE6 and stuff. Now, that's considered very, very bad.

The people who are implementing stuff in a browser, when they get a little stuck or a little confused or they're like, "I don't know what this means," then they're supposed to go back to the working group and be like, "Hey, don't know what this means. You all need to work this out," and then there's a conversation. Everybody has a chance to talk about it.

Microsoft, for instance, yesterday; I don't know that they've started working on subgrid yet, but their engineers very much wanted to have a say in the decision that was made so that, when it's time for them to implement, what they're implementing is what they want to implement. Right? We had a little conversation about that. It's good. It works well.

The problem is that I think there are some folks at some browser makes, maybe especially not working on CSS but working on JavaScript or other things, that don't really understand this process and they're sort of really impatient. They really just want to get a promotion and the best way for them, they think, to get a promotion is to write a spec and land it in the browser. They just want to do it really fast, and they don't want to talk to anybody. They don't want to go to meetings.

Maybe some working groups don't even have meetings on phone calls or in person. They just do everything like GitHub issues and they don't want to talk to people. They just want to do it.

Sometimes, there are situations where browsers are just shipping stuff way too quickly and it's not necessarily very good. They're not talking to everybody else and it's frustrating. It's really, really frustrating.

It's one of the things that, at Mozilla, one of the values that Mozilla really brings to the table is this desire to make sure that things are being specified properly and that there really is a healthy conversation around everything and no one is rushing to ship because of some massive team at their company who wants something for their particular Web property that that company is running or something.

Chris: Mm-hmm. The worst possible thing that anybody in this player could do would be to do the thing where you just invent this thing that you want and you literally just ship it; no flag, nothing, nothing.

Jen: Yeah.

Chris: Isn't that, like--

Dave: The Dave element, I believe, is what we're all talking about.

[Laughter]

Dave: The Dave element, it's a picture of my face.

Chris: Yeah.

Dave: It shows up in every browser.

Chris: If some browser did that, it would be great for Dave and bad for the world.

Dave: Yeah, my brand. Yep.

Jen: Well, and that browser might be like, "Ooh, this is the Dave browser. Dave browsers are cool."

Dave: Yeah.

Jen: This browser is cool. Why are the other browsers being so lame? They don't have the data on it.

Chris: They probably would do that. They would market it as a competitive advantage for themselves.

Dave: It's a minus point in your compat chart.

Jen: Welcome to Netscape 3, Internet Explorer 3 days. That's how we started. We did that once already. It worked out really badly.

Chris: Well, as time goes on, people are going to forget about that. Business-wise, it's going to start to feel like it makes more and more sense to do things independently for competitive advantage. It's a miracle to me that it hasn't happened yet. It almost seems like there needs to be some kind of -- who watches the watchman or whatever kind of situation here.

Dave: All good.

Chris: So far so good. [Laughter]

Dave: Sign me up. Sure. We'll do it.

Chris: I just think it's cool that--

Dave: I'll be judge and arbiter. [Laughter]

Chris: Yeah. I don't stay up at night thinking about it, but it just seems to me like it's going to happen. At some point, there's going to be some throats cut here or whatever. You know what I mean? Badness will return to this.

Jen: Yeah, it is already happening. I think it happens more on the JavaScript side than anywhere else, but that's just a handwave-y. I'm not sure-sure.

People are like, "We want the Web to be as powerful as native. We need to hurry up and make the Web better. We don't have time for all this talking and talking. We just need to hurry up."

The thing that's different, because you're right, Chris, anyone who works on an engineering team kind of has this dynamic already happening. The thing about a small team or, I guess, I should say a smaller team, not these 1,000-people teams, but the smaller teams where you're building your own website or whatever. You can always delete all your code later. You can always say, "Oh, this thing I shipped quickly for my project, that was a bad idea. Let's obliterate it and redo it better later."

With the Web, there are two things. One, we don't get to change it and ship it again later almost ever, right? If we hurry up and we ship subgrid and subgrid is crappy, there's no fixing it. We're stuck with it, right? We talked about subgrid extensively to make sure it wasn't crappy.

The other thing is that we're not solving for one website. We're not solving for Facebook.com, YouTube.com, CodePen.io, or for whatever. We're solving for the entire Web and every use case ever all at the same time. [Laughter] That's really hard.

Dave: Yes.

Chris: Yes. I can imagine. Yeah.

Jen: There are folks, I think, and there is a younger generation of folks who are coming along now who weren't around when IE4 and Netscape 4 were so completely different from each other that you had to literally build two websites. They don't remember why IE6 was actually a really, really good browser because it finally -- like the beginning of the Web standards movement, this newer, younger generation just wasn't there.

How do we hand down the lessons that we learned then? How do we teach people that I know it can be a pain in the ass to talk to humans, but there are actually really good reasons to do that. If we want the Web to be awesome in 10 years, in 20 years, 50 years, this is what it means to be responsible stewards of the keepers of the people who make Web technology.

Chris: Mm-hmm. Such big -- that's a just -- ooh, that's a heavy burden. Heavy burden to bear there.

Jen: Yeah, I mean the CSS working group, to me, in a way, is kind of like a miracle. It's like this crazy, holy ground where this miracle happens. Some of it is born of friction. Some of it is born of disagreement.

Chris: Mm-hmm.

Jen: That I don't think is necessarily a bad thing.

Dave: Yeah, I guess the criticism there would be like CSS, the C in CSS stands for compromise, I guess.

[Laughter]

Dave: Is that maybe true? Is it watered down because, quite literally, everybody on the Internet can hop into the forum and holler off? Is it compromised or watered down?

Jen: I don't think so. I think it actually is just way better-better-better. At least the version of the CSS working group that is the modern era, the last five years, the way that things have been running and what I've seen, it works really well.

Oh, you want to do whatever, like vertical text. You want to do subgrid and you think, oh, this is going to be -- underlines is a good example. We're going to do underlines. Let's just do underlines. Hurry up. Let's just style underlines.

It's like, yeah, but what about these languages that are typeset vertically? What is the typography in Japan? What's needed for this kind of scripts that's completely different than an alphabet?

Dave: Mm-hmm.

Jen: There's a long conversation about that. Then, wow, we're shipping something that actually works for all the languages and all the scripts around the world, or it almost does and there are a few pieces missing, but we're dedicated to going ahead and finishing those pieces as soon as we can.

Chris: That's another difference between what you're doing and what an individual website has to do.

Jen: Yeah.

Chris: If there's too much edge case talking at a Web app, you're like, oh, my God. We're not doing anything. Everybody is just talking about these little problems we may or may not have, but you have to do that because you really do speak for the entire Internet and make decisions that are the entire Internet. I often find that distracting when a blog or discussions are had about what technology should be picked or what's good or bad for the Web. They talk about it in such broad terms that they're trying to apply it to every website under the sun. I don't think that that's necessary or appropriate because you're really just talking about one website and how that gets implemented.

Jen: Yeah.

Chris: But it's exactly the opposite again in your shoes, or in the CSS working group shoes, or in browser shoes, when you really do need to think about every single website in the world.

Jen: Yeah.

Chris: Yeah.

Dave: I think a very recent example, probably near and dear to your heart, Jen, would be like grid. The first one showed up in Microsoft or Internet Explorer - sorry.

Jen: Yeah.

Dave: It was like the MS Grid. This was kind of them doing it themselves, in a way, because they were trying to hit some Windows A/B objectives or something or MSN.com objectives. It was good but also incomplete. It didn't have everything it needed to actually do a whole layout and so that was behind a prefix, but then it got hammered out and is now great.

Jen: Yeah. Yeah.

Dave: Maybe you know that whole story.

Jen: Well, and Bert Bos had this earlier version and this earlier idea of how a layout might happen and he wrote it up as a spec that ended up being called the Template Layout spec. Then Microsoft, yeah, like you said, they came along around the Windows 10 era. I think it was sort of inspired by Metro, the Windows Metro UI, and trying to fulfill needs inside Windows, inside Microsoft, to support that kind of operating system design with something in CSS. I don't know the details, but my sense is that those two things were probably connected.

Dave: Mm-hmm.

Jen: Meanwhile, in previous iterations, Mozilla had some ideas about how layouts should happen and we created this thing called Zulu, and that sort of ended up becoming what we have in Flexbox. In a way, it was sort of these competing ideas of what layouts should be. all of them were coming after the original ideas around absolute positioning and stuff, which turned out to not work at all. They were sort of a train wreck.

It was years and years and years of all these different ideas and all these different competing conversations. I think, earlier in this sort of template layout Bert Bos, Hakon Lie eras, I don't know that those conversations were going very well. I think that there was some tension that ended up with, like, "Well, then we just won't do anything then." Right? [Laughter] It was only after--

Dave: That was a tense time for browsers, too.

Jen: Yeah.

Dave: There were so many power plays.

Jen: Yeah.

Dave: Literally, corporations trying to own the Internet.

Jen: Yeah.

Chris: Mm-hmm.

Dave: For all intents and purposes.

Jen: There was an incredible amount of technical debt that had to be paid down because there wasn't good specifications in the era of CSS 1 and CSS 2, and there wasn't a lot of what we call interoperability, like different browsers would interpret CSS in completely different ways. The box model was interpreted completely different by different browsers. It took years and years to solve all of that. The working group spent a lot of time paying off all that technical debt.

Then once that happened, they were able to come in and focus on layout. Yeah, Microsoft took their first stab and it was behind a prefix although, today, they would be doing that same kind of work behind a flag.

Dave: Mm-hmm.

Jen: It helps to have an implementation, so it's not a theoretical conversation. You actually have a running implementation as an experiment. You can play with it, look at it, and say, "Does this work?" Then there was a long conversation and it took about five years to figure out, well, what if we took these ideas from Bert's thing and we morphed them together with these ideas from Windows and this new Microsoft thing?

They matched those two ideas together and wrote the real grid spec, and that got implemented in all those browsers and shipped in March of 2017. I think that that's a real success story. I think some people look at it as a real failure somehow that because it took five years, but I think, you know--I don't know--maybe it could have taken four years instead of five.

Dave: I think that's a good example of, it got implemented half good, but then it got fixed through the standards process.

Jen: Yeah.

Dave: And got better. I did have a zinger for you while we're talking about grid, if you can.

Jen: Yeah.

Dave: What are your thoughts on the grid shorthand: use it or lose it?

[Laughter]

Jen: I don't use the grid shorthand much because I can't remember--

Dave: Yes! That was my answer.

Jen: I can't remember it. I like just writing the long -- I just write the long stuff.

Chris: But there's like 20 properties involved. Shorthand for which one? Any of them?

Jen: I actually don't use named areas much. I actually use numbers too because I don't use named areas or named lines much. Also, I'm not writing production code for a big team. I'm not making a design system. I'm teaching tutorials, so I'm weird.

Dave: Nope. I'm telling my team right now, "Jen doesn't use the grid shorthand." Problem solved. Done. Resolved. Mark as resolved.

[Laughter]

Jen: One fixed. Closed.

Dave: Done. Yeah.

[Banjo music]

Chris Enns: This episode is sponsored by Datadog Synthetics. You can get a user's eye view of your front-end services with Datadog Synthetics. Automatically test your application endpoints with simulated traffic from global locations, which allows your team to proactively identify and improve issues before they affect your customers. Plus, you can build multistep browser tests simply by interacting with your application.

Datadog will do this really cool thing where it'll record your actions and automatically execute the tests and intelligently adapt to changes in your UI along the way. You can build your first test today with a free trial of Datadog synthetics and receive a complimentary T-shirt.

With Datadog, you'll be able to proactively monitor site availability and uptime, monitor critical business transactions and user journeys across your app, and create tests in minutes with their Web recorder. Datadog will help you save time with AI-driven, self-maintaining tests so you can stay focused on building new features, not fixing brittle tests. Datadog will reduce mean time to resolution with full-stack visibility. You can accelerate development with the end-to-end context in a single platform and break down your silos.

Follow the link in the show notes or in your podcast player right now and sign up for a free trial of Datadog Synthetics and get yourself a free T-shirt in the process. Our thanks to Datadog Synthetics for sponsoring this episode.

[Banjo music]

Chris: I have CSS. Any value that ends up having a slash in it, I just abort. I'm like, "Oh--"

Dave: [Laughter]

Jen: Huh.

Chris: Anything. Grid is almost an exception in that if you go grid column one/three, I kind of get it.

Jen: Yeah, I use that.

Chris: But sometimes there are multiple slashes and border-radius can have a slash. Even if border-radius has a slash, I'm out.

Jen: [Laughter] It's funny because I know more about CSS than I've ever known in my entire life. I understand it so much more deeply. I'm almost embarrassed that I used to say that I know it because I didn't. Also, I have been more aware of what I don't know at this point than I have ever been in my whole life. There is so much stuff I don't know.

I'm constantly quickly looking things up because I have no idea. Yeah. There's a lot to know. It's kind of an amazing language.

I think it's designed in such a way that people can use it in many different -- like, there are many different corrects. There are many different ways to write it. If the shorthand is helpful for somebody, then cool. If they're not, then okay.

Dave: Well, I think it's nice. It's that thing like animation shorthand is pretty darn helpful because I hate typing out all those properties. I use that one all the time or transition shorthand.

Background, I think Harry -- I almost said Harry Styles. That's not CSS wizardry. Harry -- why am I blanking on Harry's last name? Anyway--

Chris: Roberts?

Dave: Roberts. There it is. He was saying he's kind of backed away from background shorthand because too often you're like, I want to update the background color or image and then everything messes up.

Chris: The classic one there is it makes repeat.

Dave: Oh, yeah.

Chris: Repeat is the default for whatever reason, which almost nobody ever wants.

Jen: Oh, yeah. Yeah, the thing about using a shorthand, any time you use a shorthand, you might intend to only change the things that you say in the shorthand and let the other properties for that overall thing be whatever they were in the longhand that you wrote above it higher up in the cascade. The thing is that when you use a shorthand, you frequently end up resetting a lot of stuff that you didn't mean to reset. You kind of have to end up saying all the things in a shorthand or you end up with unintended consequences.

Chris: Sometimes that's good and sometimes it's not.

Jen: Yeah.

Chris: In background, it's bad. In Flexbox, it's good. [Laughter] Although, just know what you're doing is the real answer, unfortunately.

Dave: Flex 001 50% niner.

Jen: [Laughter]

Chris: Yeah, but that's good. There are other things happening there that you want to happen. Anyway, that's a deep dive.

There was one thing I want to make sure that we touch on while Jen is here because this influences the Web in a very positive direction, which is this aspect ratio of images thing. The first time I heard about it from Jen, it was like, "Look, there's going to be this aspect ratio property." In CSS, in fact, I think there still might be, or whatever.

Jen: Yes. Yeah.

Chris: Perhaps, and this still a way that you can think about it. I think the mental model of this remains. What under the hood happens might be different. It kind of doesn't matter.

Actually. You know what? Can you do it? I'm tempted to do it, but I think you're going to have a better explanation than I will.

Jen: Yeah, so I'll also tell a little bit of the story of what happened. There are many problems that front-end developers have, problems that there's no solution. One of them is, you put a YouTube or a Vimeo or some other kind of video on a webpage and it's not actually a video element. It's an iFrame, right? You want to put a width 100% on it or you have something else similar. You want to put width 100% on it and you want it to maintain its aspect ratio and it doesn't.

You've got to go get yourself a little JavaScript framework, a little JavaScript plugin, or you've got to go get yourself a little padding hack trick thing, which is annoying.

Chris: We know all too well here.

Dave: All too familiar.

Jen: Yeah.

Dave: Yes.

Jen: To me, any time there's a hack that we all teach each other, that should become a real thing in CSS.

Dave: That's a cow path, right?

Chris: Mm-hmm.

Jen: Yes, pave that cow path.

Dave: Yeah.

Jen: I was like, let's add an aspect ratio to CSS. We'll add a property. At this point, after discussing it for a while, I think right now the current proposal is, you put aspect-ratio: and then you put the thing, like 16/9. Sorry, there's a slash.

Chris: Mm-hmm. Hate it.

Dave: Oh, it's on Chris's--

[Laughter]

Dave: --S-H-I-T list. Yeah.

Chris: In this case, it's not a slash is part of the value. It's a--

Jen: A fraction.

Chris: It's a fraction.

Dave: A fraction.

Chris: The whole thing is the value.

Dave: Yeah.

Jen: Yeah, and I think we actually are going to allow numbers, too. You could say 1.77 if you wanted to instead. We're debating a little bit of that still, but I think it's mostly done. You could say, aspect-ration:1.777777777 or you could say aspect-ratio:16/9.

What that would do is it would give an element, that doesn't have an intrinsic aspect ratio already, it would give it an extrinsic aspect ratio or, if you did have an intrinsic aspect ratio on an element, it would override it and give it a new extrinsic aspect ratio. What that would mean is you could say, width 100%, height auto. You'd have to say height auto. You'd say height auto, and then you'd say aspect ratio 16/9 and it would be like, okay, well, I'll calculate the width and then I'll times that or divide it by 1.77 and it gets you the height. Cool.

In the midst of creating that, that doesn't exist in any browser yet, although I know that we're putting it on the roadmap to implement it in Firefox pretty soon. Hopefully, over the winter. But along the way, while we were talking about this and discussing it, I was talking to Elika and talking to Emilio and talking to other really super smart people in the working group who actually understand how the rendering engine works, which I don't understand that. They understand how the rendering engine works. They write C++ for a living to make the rendering engine exist.

We got into it, and we were like, hey, you know, can't we just sort of take this? I said, can't we just jam this in the user agent stylesheet and have it be like aspect ratio, take the width attribute and put it over the height attribute so that you could just grab the attribute information out of the HTML and use it on the first paint to calculate the layout of the page to get rid of this problem that's like the jank problem, which we can explain in a second for folks who maybe don't know what that is? That conversation went on. What Emilio and folks at Mozilla were like, "Oh, you know what? We don't even need the CSS part of it. We wouldn't put it in the UA stylesheet. We're just going to go ahead and do this straight in the browser. Like, we're just going to put it straight in the browser."

Chris: The layout engine? Yeah.

Jen: In the layout engine before the CSS happens.

Dave: If I write width 400, height 300, I get a 4x3 box.

Chris: But you would anyway.

Jen: Right, so this is the problem. Let's say you have an image that is width 400 pixels, in height 300 pixels. It's 1997, and you put this image on the webpage. That's what we did in 1997. You put image and then you put the URL and then you put the width and the height attributes. The reason you did that is because of modems, slow Internet, and it meant that the moment the HTML was read, before the image was downloaded, the browser would know to carve a hole that was 300 pixels tall and 400 pixels wide. It would slowly load the image into that space. Awesome. Perfect for performance. Then--

Dave: Love it. I'm going to see Chasing Amy later.

[Laughter]

Jen: everyone knew. Well, not everybody, but that was the best practice that we would teach each other is always include height and width. It helps with performance. You definitely want your height and width attributes. That was true--

Chris: Remember that no other resources need to load to know that information.

Jen: Yeah.

Chris: It's in the HTML. Maybe the image starts loading right away. Maybe there's some sort of weird delay and the image doesn't start loading. Whatever that delay is, it doesn't matter because the data is known from the HTML. The data doesn't come out of the image file itself.

Switch to 2010. We start putting width 100% in CSS on those images. If the image gets resized so that it's wider than 400 pixels, let's say it's going to be 800 pixels. Then we can quickly do the math and say, well, if the width of the image is supposed to be 800 pixels, then the height should be 600 pixels, but the browser didn't have any way to do that calculation. The browser was like, "I don't know how big this image is. I think I will wait until the image loads. Meanwhile, I'm going to assume that it's zero pixels tall."

Chris: Zero.

Dave: Mm-hmm.

Chris: Yeah.

Jen: Zero pixels tall, so it actually--

Dave: Yeah, everyone's zero by zero image.

Jen: Yeah. No, I think--

Dave: Yeah, everyone loves it.

Jen: I think, and I could be wrong, but I think it would actually calculate the width correctly so it would make a box that was 800 pixels wide and zero pixels tall.

Dave: Hmm.

Jen: The problem with that is then the very first paint of the page, let's say especially if you have a whole bunch of images, all the images are zero pixels tall and all the text gets rendered. You start reading the article. The user starts reading the article and maybe they even scroll and they read part of the article. Then the images load and the browser sees how big the images are. It grabs that math and it recalculates and repaints the page. It's like, "Oh, we need to put 600 pixels here. Let me scoot that text down." This has probably happened to all of us where you're reading an article and literally, as you're reading it, it's jumping up and down and you have to keep moving the scroll.

Chris: Yeah, that's the jank thing that you're describing. The irony is that you'd think, oh, us three, we're some genius front-end developers; we'll solve this with some kind of genius way to get around it. There actually is a really weird way around it, but nobody does it. I don't do it. I think the only way you'd do it is that weird padding-bottom trick.

Ain't nobody wrapping their arbitrarily sized images in arbitrarily padding-bottom. We just admit defeat. This is just a janky part of the Web and there's no way to solve it in a responsive column. Along comes Jen Simmons and you're all [laughter] -- in this user agent style sheet idea with this automatically calculated ratio. It really is the answer.

Jen: There was what's called a YCG group, a Web interest community group - something. I forget what that stands for, but the responsive images community group that got together and discussed responsive images--

Chris: Mm-hmm.

Jen: --the picture element, and all that stuff for a long time. Sort of a spinoff of that work was another YCG group. This is sort of outside the specification process, but it's like the place for anyone. Any community member could go and start working on a spec and propose ideas for a spec, even if they're not members of the spec groups or they're not official. They don't work for browsers or whatever. YCG is a cool place that anybody could contribute to the ideas that might become a specification later.

There was a group of people who were like, "Hey, let's solve this jank problem," and they wanted to invent a new attribute. They were debating to add this attribute called aspect ratio. It would have the syntax of 16x9 or that you would add aspect ratio data to every single one of your images.

I was just like, I don't want to add new data. Why should we invent something new? What we should do is we should take the width and the height and we should put them back. We should make sure that they're on our images again, just like it's 1997. Use the thing.

I think that that's a feeling that I have from inside the CSS working group where sometimes things that exist already in CSS aren't necessarily ideal but they already exist and so there is kind of this principle of, sure; if we had a time machine, we would have done it better before, but we don't. Since we already have such and such syntax for one property, now that we're inventing a new property, let's use the same kind of syntax because we want there to be consistency.

There are certain properties. Don't make things harder. Don't redo something different because it's technically more pure in the present than it was in the past. It's better for authors if it's consistent; if things are sort of the same.

To me, it's better to use width and height because that's what we've been using the entire time than to invent a new attribute. It just kind of was like this moment of, like, why don't we just do it this way? Why aren't we already taking the width and height attributes and putting them into the calculations so that, even if width 100% is applied to something, that the browser goes ahead and it grabs those attributes? It uses it in the first paint.

If it turns out -- this was a little bit of a debate, but this is how it landed. If it turns out that somehow the width and height attributes are wrong and the aspect ratio that gets calculated from them is different than the aspect ratio that's inherently inside the image, then it will get recalculated and it will be painted a second time. The image itself will beat out the calculation based on the attributes but, in any case, what it means is if you put the proper width and height attributes on every single solitary image on every single website right now, responsive images are not flexible media. You will get a much better experience. You'll eliminate this jank.

Dave: I think this aligns with the design system methodology. It's like, is there something we can use that we have already?

Jen: Yes.

Chris: Well, that's the big deal is that it's not like, oh, we've invented some way that authors in the future can solve this problem. No, we're going to take something that miraculously already exists and just improve the loading experience for just countless sites with this change. What a tremendous improvement for the Web. Just incredible. I love it.

Jen: Thanks. Yeah, so the TLDR. Every website should put width and height attributes on every single image and, if you've taken them off, which I think lots of people have because, for a while you didn't get a performance benefit.

Chris: Right.

Jen: If you had a width of, like 400 pixels or--what were we using--600, you have a width of 600 pixels and then you put a width of 100%, it will change the width. Then if you had a height of 400 pixels, it would do with of 100%--

Chris: It might even screw it up.

Jen: --and height of 400 pixels. You would squoosh; you would lose the aspect ratio.

Chris: Right. You'd have to be really careful with your auto and your CSS.

Jen: Basically, you have to have width auto on there. I remember, for a little while, being like, I don't want to write width auto. I just want to write -- I mean I don't want to write height auto. I just want to write width 100%. I don't want to write two lines of CSS. I want to write one line of CSS.

Oh, if I remember my width and height attributes, I can simplify my CSS. Awesome. I'm totally doing that. Right?

Chris: And make my HTML just a little lighter while you're doing it.

Jen: Yeah.

Chris: I removed them because I have a system. A lot of us are like, don't write a ton of raw HTML. I'm sure lots of people do, but a lot of people use CMSs. They use JSX. They use stuff that craft the HTML that ends up in the DOM for them. Then, because you have that abstraction in front of you, you can just very quickly say, "Ah-ah, just forget the width and height. They're not giving me any value anyway. Just rip it off."

I guess what you're saying is, if you've done that, revisit that abstraction and put them back if you can. I know that I -- on CSS-Tricks, I removed them because I have a special image filter thing that wraps it in a figure tag and does responsive images. I revisited it just recently because I added loading equals lazy to them because that's a thing that exists now in Chrome.

Jen: Yeah.

Chris: Why not take advantage of free lazy loading. Just chuck that on there. At the same time, that same filtering that removed those width and height attributes, you better believe I'm going to put them back because it's going to have amazing performance benefits for free starting very soon if not already. Right?

Jen: Yeah. Yeah, so put width and height back and you're probably going to have to add height auto or whatever. It might be width auto, but you'd have to--

Dave: Do your image reset.

Jen: Yeah, to just adjust your CSS a little bit. Don't just do the HTML and not QA your website.

[Laughter]

Jen: Make sure you've got height auto in there so that you don't screw up your images.

Dave: Nope. You heard it. Jen said just save it and ship it to production. Don't even check it.

Jen: [Laughter] Yeah.

Dave: Maybe this is too long of a conversation. One thing I use picture for is switching the aspect ratio, like 4x3 on mobile, 16x9 on desktop, or something, you know, to kind of change the aspect. Do I have a vehicle to change the aspect?

Jen: Good question. First, I'm going to answer the question that comes right before that, which is, what about using image with source set? Not picture. Not changing aspect ratios. Not art direction. You have image and you have source set. Maybe your default image is 400x600, but you've got all these other images--

Dave: Yeah.

Jen: --and all these other copies that are different resolutions. Well, when you're using image and source set, all of those variations for retina and all that stuff are the same aspect ratio. If your original image element has width and height of 400 and 600, that's going to give you a 2x3 aspect ratio or 3x2 aspect ratio. If all of your other images and all of your other copies are also all 3x2, it's fine that the numbers aren't the same. It's fine.

Dave: Mm-hmm.

Chris: They're supposed to be with source set, aren't they? Isn't that, like, what we asked to do--?

Jen: Yeah, they're supposed to. Yeah.

Chris: Yeah.

Jen: They're supposed to all have the same aspect ratio. It's totally fine if this one is 200x300 and this one is 800 by whatever that math is. It's cool. Don't worry about the fact that the numbers aren't quite right. It's the ratio that matters.

Chris: Yeah, but picture is different. Is that where you're going?

Jen: Picture is different. Yeah, picture is different, so you could easily have source set where you've got this 2x3 photo sometimes, but other times you have a 2x1 photo and other times you have a 1x1 photo. Sometimes it's a square. Sometimes it's a wide rectangle. Sometimes it's a more narrow rectangle.

We don't have that yet. There's a debate happening right now. What are we going to do? I think it's pretty clear, but we haven't finished. This is the specification process. I think what we're going to land on is, we're going to put width and height attributes on source elements.

Chris: Oh, wow. Sure. Yeah, that makes sense to me. Without participating in any nuanced conversation, I already don't hate it.

Jen: [Laughter] Already don't hate it. That's a good sign.

[Laughter]

Dave: That's the testimonial section of the spec, "Already don't hate it."

Jen: Already don't hate it. I think it makes a lot of sense because, basically, the source attribute, the SRC attribute on the source element, S-O-R--

Chris: Yeah, there's only one of them.

Jen: S-O-U-R-S. Right.

Chris: And it has an aspect ratio.

Jen: And it gets swapped out, right? It takes the URL for the image file and it swaps it into the URL for the image file on the image element. Why not just go ahead and take the height and width attributes out of the source element and swap them into the height and width attributes on the image element? That's the proposal as of October 10th, 2019.

There was a little bit of debate; well, maybe the height and width should go onto the picture element. Then I was talking to Elika about it yesterday. It was like, I don't think that makes -- to me, with the picture, uh-uh. That's what I was tweeting at yesterday, like, who uses picture? What do you use it for?

Chris: Well, that's a fascinating little discussion, too. It's one of those, what do people--? I think that's what you're trying to get feedback on. What's your mental model of how a picture works? Do you assume that it's replaced?

Jen: Yeah.

Chris: Or do you assume that it's sitting there in the DOM.

Jen: As a wrapper.

Chris: Yeah, like a div or whatever. It's just something around the image.

Jen: Right, or do you assume--

Chris: My brain is exactly split.

Jen: Is it either?

Chris: Oh… Yeah, it's exactly split between -- I don't know. It's like a block-level thing. It just wraps around. It's like an article, a section, or anything. It's a thing and of course I can style it. I'll put a border on it if I want. Maybe that's the right place to put a border, in some cases, if that's my style.

Some of me is like, don't trust it. No, no, no, no, no. With this weird -- hmm -- with the weird--

Jen: Oh, you're right.

Chris: Yeah.

Jen: You're right because the first one is what I think, too, is purist, especially. That's what I think but the second is true.

Dave: Hmm. Wow.

Jen: There was one particular evening on the CSS working group face-to-face meeting where Emilio, Elika, and I and, I think, Amalia was there and some other people. We were laughing our heads off [laughter]--talk about nerdiness--because we realized that the picture element, the default CSS that's been assigned to the picture element is a crap pile of "What?!" and it does really weird things. It should have been better specified in the HTML working group so that it would be better.

I think that's one of the things we want to go back in and clean up because if you put borders on the boxes so you can actually see them, it's really strange what the picture boxes are doing. I think there's a good reason for folks who have an instinct that you can't quite trust a picture because you can't. [Laughter] It should have been better specified.

Dave: If I recall, it was not the most popular element in the working group.

Jen: [Laughter]

Dave: It sort of showed up by brute force.

Jen: Yeah. I think, as an HTML element, it's awesome. It's just sort of the default CSS part got a little fallen through the cracks.

Dave: Well, yeah.

Jen: It would have been nice if some CSS working group people had been involved at some point or something. I don't know.

Dave: I think, yeah, in general, we probably could have caught this aspect ratio if it would have gotten just a smidge more of attention, like, you know, back then.

Jen: But also, literally, this is always going to be what this is because it's a bunch of humans.

Dave: Mm-hmm.

Jen: Sort of pointing and saying, "There's something wrong here. We need to destroy the process or change the process," I think is really unrealistic. Or to say someone did something bad. No, this is just how it goes, so we're going to make it better as much as we can and we're going to keep it the same as much as we have to. We're going to keep moving forward, you know.

Dave: Maybe a good place to wrap this up, because I know we've got to get going, but if there's a feature that I want and, boy, does Dave Rupert have a list, but how do I start? What do I do to get something in a browser? What would be your starting point? What would you recommend?

Jen: Write a blog post that describes what use case you're trying to solve.

Dave: Okay.

Jen: You're working on your website for your job or whatever and you're like, "Oh, my gosh. We keep running into this problem. We're doing this particular thing all the time and there's no good technology to solve this. We need a tool that solves this."

If you want to write an idea about a solution, that's cool, but you don't even really need to do that part.

Chris: Yeah.

Jen: Just the part that describes the problem is disproportionately impactful on the working groups. It's amazing how much a blog post like that, even if you think, "No one reads my blog," yeah, that's fine. If you're saying something, if you're describing a problem that a lot of people have and you put that blog post out on Twitter, other people are going to be like, "Me too! Absolutely! I agree." It's going to get read. It's going to get attention.

Somehow, miraculously, the right people in the right working groups are going to see it and they will use that because they probably actually already agree and probably already are thinking about that. Your use case and your description of your use case will be super helpful for convincing their bosses to let them work on it or making it a higher priority because lots of people are asking for it. Clarifying the actual business use cases and the needs of everyday Web designers and Web developers, it makes a big difference. It really does.

Chris: Mm-hmm. I'm sure a lot more of this than I have, but I feel like I've seen a good amount. The mistake that you can make here is, instead of describing your problem and your workaround or your use case is to only blog about your idea, your solution.

Jen: Yeah. Yeah.

Chris: Then you get attached to what your solution is instead of describing that problem upfront.

Jen: Yeah.

Chris: I feel like I've seen that a lot. You're like, "Yeah, I kind of get what you're saying here." Yeah, right, it's way less effective.

Jen: It doesn't work very well for two reasons. One is, probably your solution isn't very good. If you get too attached to it, it's not going to go anywhere. Probably, there are going to be a bunch of ideas about solutions and they're going to all need to be thrown out and, like the 14th version is what's going to be the thing, not the first version.

The other thing is that I think people underestimate how really amazing and genius the folks inside the working groups are. [Laughter] Especially, I know this about CSS; I don't really know this so much about HTML of JavaScript. On the CSS, I'll see people pop up and be like, "I know how CSS should work. It should work like this. Those people in the working group are stupid. They don't know anything about what it means to be a real Web developer. I'm the one who knows."

Actually, the idea that they're articulating, the solution that they're articulating is very, very naive and they actually have no idea what they're talking about because they have no idea how rendering engines work. They're kind of making a fool of themselves. They're embarrassing themselves and they're insulting a bunch of people who they need to have as their friends.

It's not that that idea still won't take off because people are so used to it. They're just like, "Yeah, I know. People say this about us. Yeah, they do. It's really wrong." It's not that bad to do that, but it's not -- you're embarrassing yourself.

Chris: There's something counterintuitive about it. I kind of get where people's minds are where they think they're being more helpful by describing the solution and being attached to it.

Jen: Yeah. Yeah.

Chris: Just whining about your problems doesn't seem useful, so I'm glad that we're talking about this on the show.

Jen: Uh-huh.

Dave: Are you guys throwing my blog under the bus? You're just throwing my whole blog under the bus.

[Laughter]

Dave: I am insulted.

Jen: I mean feel free to kick around some solutions.

Chris: Yeah.

Jen: Feel free to say, "Maybe if I had a property that was like this and worked like this, that would be super cool." There's nothing wrong with that, but you don't have to go deep into what you think the solution is going to be. You don't need to try to write the spec. You don't need to try to--

Chris: Here's an example. The parent selector is always asked for in CSS.

Jen: Mm-hmm.

Chris: I feel like--I don't know--every couple of weeks, something happens. I'm writing code. I'm like, "Oh, that'd be useful to have that. I wish I had that." Then I forget what it is. Right now, if you asked me, "Chris, describe a use case where you need a parent selector in CSS," I'll be like--

Jen: Right.

Chris: Mmmmm… I can't. But I can but I can't, you know. If I could capture that moment where I needed it--

Jen: Yeah.

Chris: --and blog about that moment--

Jen: Yes.

Chris: --that's more useful than me just writing yet another blog post that says, "I think we should have parent selectors in CSS."

Jen: It's a perfect example because parent selectors have been discussed a lot and so have container queries or element queries.

Chris: Yeah.

Jen: In some ways, they're related because when the CSS working group starts thinking about these things or talking about them, I see everybody's brains start to spin. They're like, uh… They're trying to figure out whether or not the rendering engine could ever get anywhere close to doing anything like that without just dropping into an infinite loop that would destroy performance.

It's almost like, why bother to spend four months trying to answer this question when the answer is going to be, "You're dividing by zero. This will never work. You can't. This is impossible. You can't do this"? But, eventually, probably, somebody will dive in and say, "You know what? I'm going to work on this. I'm going to see if I can figure this out."

When they go to do that, if they have a little pile of very specific use cases that will help them put their brain back on track over and over and over again as they try to figure out if the ideas they're having will get close to what's needed or not. They don't have those use cases in their own arsenal because these people are not people who make websites for a living. They don't know what it is that you experience, Chris, or what it is that you were needing at that moment.

Chris: Mm-hmm.

Jen: If you can't even remember, the working groups also forget these things quickly too. Having those documented really helps because when somebody actually sits down to figure out whether or not it's possible to do container queries or element queries, if they have six or eight use cases that they can just point to, then they can figure out quickly. Probably what will happen is they'll be like, "Well, we think everybody wants this golden, shiny unicorn, but could I just build a golden horse? Could I just get a yellow horse? Is a yellow horse close enough?" If they have the use cases, they can be like, "Yeah, you know what? A yellow horse would be fine. They don't need a gold unicorn."

Or they'd be like, "Nope. It's not about having a horse. It is about having a rhinoceros. A rhinoceros will work because they need the horn. The horn is the part."

[Laughter]

Jen: Those use cases are really important and that's a good thing people can do is help define those.

Chris: Well, that's a fantastic place for people to stop and reflect upon.

Dave: Yeah. Thank you so much, Jen. Always wonderful to have you on. Thank you. For those who aren't following you and giving you money, how can they do that?

Jen: They can follow me on Twitter, @JenSimmons. They can check out labs.jensimmons.com where I put tons of examples. They can go to YouTube.com/MozillaDeveloper to see our new channel. They can go to YouTube.com/LayoutLand to see all of my layout graphic design videos, including a bunch of conference talks from the last couple of years. The give me money, TBA. I think there are plans in 2020, perhaps, where Mozilla will be asking folks to help be part of a deeper experience and help fund the kinds of content that we're putting out for free right now on YouTube.

Also, check out Firefox. There are going to be things happening in the future with Firefox like free accounts. You can make free Firefox accounts but, in the future, I think there'll be some extra special, amazing things that perhaps you'd want to pay a little bit of money for. All of that money is going to help fund Mozilla, which helps fund the work that we're able to do inside Mozilla.

Dave: Awesome. Well, cool. Well, thank you so much and thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. 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, just like this company.

Chris: Hey, Shop-o-maniacs. We've got a job to tell you about, a really nice job opening that I think will appeal to a lot of you. It's at a place called Nacelle. The URL for them is gitnacelle. They make kind of e-commerce experiences, often that have to do with Shopify, but they supercharge them, make them progressive Web apps, just make them smoking fast because then you make more money.

They're looking for a senior developer to work with them on their front-end e-commerce platform that is all JAMstack. You know we talk about JAMstack all the time. Kind of fans of it here at ShopTalk Show.

The idea is to provide superior customer buying experiences, so they have a super modern stack they're working with. GraphQL, AWS Lambda, Vue, and Nuxt is their main stuff. They're looking for a skilled senior JavaScript developer to come on board, be their thought leader, be their technical guru. Unfortunately, it's USA only, but if you can relocate to Santa Monica, California, you're good to go.

Again, Vue JS, Vue X, Nuxt, Node, AWS, they're looking for somebody with lots of experience and into this specific stack to help them build super-fast e-commerce experiences. We'll have a link right to the job posting in the show notes for this job, so go join them in Santa Monica at Nacelle.

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

Chris: Oh, just ShopTalkShow.com.