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 and all of that good stuff. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris, who do we got on the show today?

Chris Coyier: Well, we've got two absolute luminaries of the Web, heroes of mine, and, fortunately, we've met and talked many times. Both have been on the show before, so friends of the show we can call them. We have Mr. Jeffrey Zeldman. How ya doin', Jeffrey?

Jeffrey Zeldman: I'm doing swell. How are you, Chris, Dave?

Chris: Fantastic. I know sometimes we've just got to say that, don't we? [Laughter]

Jeffrey: Yeah. [Laughter]

Chris: And Eric Meyer as well. How ya doin', Eric?

Eric Meyer: Not too bad. Sweating through a hot dome summer.

Dave: Ooh...

Eric: How about the rest of y'all?

Chris: Pretty good. I was going to say that, and then you two, with your powers combined, plus another staff, also create An Event Apart, too. That's been going well, it sounds like. I mean you'd have to tell me. But from the outside, it looks like it's going well. I'm excited to be at the Denver one coming up. That's in October. Check out aneventapart.com for that.

Jeffrey: Thanks, Chris, for that timely--

Chris: Cool. It sounded like an ad, but it really wasn't. Yeah. [Laughter]

Jeffrey: Where do we send the check?

Chris: Yeah.

Eric: [Laughter]

Chris: No, it's really good. They give it to you right when you get off stage. I don't know if you all do that. It's really like a little classy touch.

00:01:49

Jeffrey: Yeah. When Eric and I started An Event Apart in December of 2005, it was after we'd both been on the Web design speaking circuit for like ten years. We really liked speaking, and we liked a lot of the people that we saw speaking, but we thought we would do -- and there were some conferences we really liked, but we also thought how would we do it. We'd make sure everybody gets paid right there. We'd pay everybody the same upfront right away. Not make them ask and beg and all that.

Single track because, at the time, the norm was you'd get split into all these different, you know, designer versus developer versus project manager all in separate rooms. Then at lunch, they're like, I don't know. What did you see?

Chris: Yeah.

Jeffrey: Yeah, so thank you.

Chris: All these years later, no one technique has won, right? There are still plenty of multitrack conferences.

Jeffrey: Right. Very true, and they're functional. They serve a purpose. We just wanted to do one where we wouldn't miss anything.

Eric: Basically. Yeah, and I've got to say the conferences that I see in the Web space do not have as many tracks as they used to. [Laughter] Right? Even the multitrack ones because when Jeffrey talks about how there were tracks against tracks, these were like eight or nine-track conferences. Right? And I'm not talking South by. I'm leaving that aside because that's crazy town.

There would be a Web design conference, and there would be literally eight concurrent tracks. If you were a keynote speaker, which was across all the tracks, that was a big deal because everyone came together. But yeah, even the multitrack conferences that we see now have two, three, four tracks, usually.

Dave: Even some one and a half tracks. I don't know if you've seen that.

Jeffrey: How does that work?

Eric: Yeah, what's that mean?

Dave: It's like half track for half the day or something. You know?

Jeffrey: Oh, yeah, yeah, yeah.

Dave: Or like two tracks for half a day.

00:04:01

Chris: Yeah. Everybody gets together for the keynote and then split up for two sessions. Then come back to the big room. Yeah, I've seen that.

Eric: Right. Okay.

Chris: Even Virtual does that.

Jeffrey: That seems insulting too. Not to the keynote speaker, but to everybody else.

Chris: Yeah. Kind of like you're half as good as that other person.

Jeffrey: Yeah.

Dave: [Laughter]

Jeffrey: Or your stuff isn't relevant.

Eric: This isn't as important. Right. Yeah. This thing you're talking about, we don't think everybody would be interested.

Jeffrey: But to us, it's a holistic thing. I guess, for me, because I started so early, you had to be a designer, a developer, a writer, everything.

Eric: Coder.

Jeffrey: That's still my favorite way. Yeah.

Eric: Yeah.

Jeffrey: You have to--

Dave: A good maybe jumping-off point, do you still have to be that? What do you think?

Jeffrey: Clearly not.

Eric: No. You don't have to be anymore. There's still a role for people who are like that who like to span.

Jeffrey: Yeah.

Eric: Actually, I think an increasingly important role is for people who like to span silos because, at a certain point, if you have enough silos or your silos are entrenched enough, you need people who can look into both and understand both and basically be an architect.

I know at least one person who is now a vice president at a major corporation and comes from that place. I think that's part of the reason that they are now in that position is that they can talk to the designers and to the coders and figure out how to align them and when there are misunderstandings and all that sort of thing.

Yeah, I mean I think there's absolutely a role for people who are more generalists. But no, Jeffrey is right. You don't have to be. There are plenty of people who--

00:05:55

Chris: Maybe it's easier to get your foot in the door, too, if you're not.

Eric: Yeah.

Chris: I don't know.

Jeffrey: Yes.

Chris: I'm even guilty of that. When I'm hiring, I'm like, I really need you to know this one specific thing, so I'm kind of hiring for that. But then once you're in, I'm like, "You can illustrate? That's crazy! We should use that!"

Jeffrey: You also need to keep--

I remember learning this when I was in advertising. I worked with a partner, Jerry Baglio. A brilliant art director, really multitalented, and he could draw. He could draw.

We were juniors. This was a long time ago, like 30 years ago. We were presenting storyboards for a commercial we wanted to do. The senior art director closed the door and said, "Who drew this?"

Jerry said, "Oh, I did. Thank you."

He said, "Don't let anyone know you can draw like this."

Dave: [Laughter]

Jeffrey: "These hacks will have you doing their storyboards, and your work will never get produced." And that is a powerful lesson. Sometimes--

I've been in work, you know, for the Web, I've been in situations where I could, like I have the skill to make 60 versions of this in - what do you call it - a design program. But I'd be taking away somebody else's work, and that's a bad use of my time.

I think generalists are good connectors, like Eric was saying. I'm in a company now, Automattic. We make WordPress and Tumblr and a bunch of stuff. But it's a very open-source ethos there, and the people who have been there a long time are generalists who code, design, and do all this stuff. All the newer people, which is like two-thirds of the company (because it's growing really fast), they're more specialists. You can see the difference.

It's all cool, and there are important reasons for both kinds of workers, but it is interesting to see that shift. When I got there, we were supposed to do -- I got there as a designer and was supposed to do really technical stuff. It's like I don't do that. I have people for that. They're like, "No, you don't."

Eric: [Laughter]

Dave: [Laughter] Surprise.

Jeffrey: "Now you've got to do it." I don't know if that will always be true because of the nature of the marketplace changing, the workforce changing, and the complexity of Web development now. I don't do it anymore because I can still write HTML and CSS, but that ain't what it looks like anymore to me. It looks very complicated to me. What do you all think?

00:08:30

Chris: Well, is it more complicated or less complicated? [Laughter] I'm kind of hoping to speak at At Event Apart and talk about how some things have actually gotten easier.

Jeffrey: Cool.

Chris: Or at least make a case for it a little bit because I think it's partially true. But I take the point. There are so few greenfield projects that are like, can you just scaffold this HTML and write some CSS behind it? The chances of that landing in your lap is pretty low. Even if the work is kind of ultimately like that, it'll be like, "Yeah, but do it within the context of this WordPress site," or "Do it within the context of this Next side, "or Nuxt, you know, some kind of complicated build tool - yadda-yadda.

Some people are just like, "Yeah, fine."

Jeffrey: New designers just working in Figma working all day long whereas, in the past, they were doing UX and writing their own HTML and CSS. The person writing the HTML and CSS may also be like a JavaScript developer and adept at five other things I don't even know about.

I suppose that's just the Web can do more stuff than when we started - than when I started.

Eric: No kidding.

Chris: We say, as we speak into a Web browser window with four human beings on it with perfect, real-time audio, video, while it's capturing your local audio into local storage - yadda-yadda. You know? Zooming its way to the cloud in a reliable fashion.

Eric: Hard to do that with 12 tags.

[Laughter]

Chris: Yeah, right.

Dave: And microformats. Microformats.

00:10:05

Jeffrey: Microformats, let's talk -- let's talk -- microformat love. We have one of the inventors, one of the co-inventors of that whole genre, Eric.

Eric: It's true.

Dave: Do you feel like, Eric, you've powered the world of search engines? [Laughter] Brought about their dominance?

Eric: Oh, good lord. I hope not.

[Laughter]

Eric: That answer comes from a very specific place. I mean part of what we were doing is we were trying to establish schema for the Web, basically, without having to write XML schema, which are incredibly... obscure. I'll use that work.

Yeah, now we have schema.org and all this kind of stuff. But where that reaction came from, really, is that one of the things that we talk about at Igalia (where I work) and a thing that I've been thinking about for a while is, if you think about it, pretty much damn near 100% of all browser development is dependent on ad revenue. That is the model that has evolved.

I don't even want to say that's the model we've built because it's not like set out to do it on purpose, but that's the deal because Mozilla, for example, and Firefox, Gecko, and all that stuff, their money comes from a default search engine deal with Google. Right? That's where those millions of dollars that pay for everybody who works on or worked on Firefox came from.

Chrome, obviously - or maybe not obviously -- being developed by Google, their ad revenue is their revenue, pretty much. Even Apple, it's search engine revenue. Of course, Apple has plenty of other cash that they can draw on if they--

Chris: You mean scope to Safari team itself?

Eric: If they wish. Yeah, I think traditionally. I'm not sure that's as true now. You all should get Jen Simmons on, if you can. I mean she--

Chris: Do you think she would tell us what kind of check Apple gets from Google?

Eric: I don't think you'd get numbers, and I don't know if Apple would let her be on a podcast because Apple gets really touchy about that kind of thing.

Chris: We've been trying. Don't worry.

Eric: Okay.

Chris: It's tricky, though.

Eric: Uh, yeah. But if you've noticed, the WebKit team has gotten much bigger very quickly since Jen got there. I don't know if she was part of that hiring or if she's driving that hiring. I don't know from the outside. But the WebKit team is getting bigger quickly, and they're shipping a lot of stuff ahead of other browsers.

People were doing "Safari is the new IE" for years. They're shipping stuff ahead of everyone else now.

Chris: Yeah, they must have got--

We did a nanna-nanna-boo-boo on Safari, and they got pissed.

[Laughter]

Eric: Well, whatever it is, that's happening, right? It makes me wonder if they've managed to get resources from elsewhere.

But when you look at it overall, the entire browser ecosystem is completely dependent on search ad revenue. That's not a great model, in my opinion.

Chris: It's too bad that it's so gross that people are like, "Uh, ads. Uh, they're tracking me everywhere I go. I'm sure this microphone is listening. I can probably watch a fetch request sending my IP out."

There are all kinds of bad stuff. But it's almost too bad because, at its core, advertising, to me, feels so positive, so yin-yang, so, like, there's this company that makes widgets, and they spend all their time and energy making the widget. They have no time to figure out how to build an audience.

Then there are all these other companies that are like, we give everything away. All we know how to do is audience. We have no widgets. We only have audience.

Those two symbiotically live together. One pays the other to reach the other person. I like the concept of advertising. It's just too bad it ended up so crappily on the Web.

Eric: And that, like I say, if ad revenue suddenly went away tomorrow, I don't know, the EU bans it or something and that becomes a global thing, I don't know where the money for browser development comes from.

Jeffrey: Right.

Dave: Tracking and all that crud mixed into it too because it's like, I don't mind seeing an ad. I mind it two weeks later when it's like, "Hey, man, you didn't buy that mattress yet."

Eric: Right.

Dave: "Do you want to buy that mattress? You should buy that mattress."

Eric: Yeah.

Chris: [Laughter]

Dave: You know? It's like, "I kind of just want to read this news article." [Laughter]

Eric: Right. Or "Hey, I see you bought a mattress. Clearly, you want to buy another one."

Dave: "You want to buy another mattress?"

Eric: Yeah.

Dave: "People buy two mattresses all the time." You know? It's pretty normal.

Eric: Don't get left out.

00:15:09

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Memberful. That's memberful.com. Link in the show notes, of course.

Memberful is the easiest way to sell memberships to your audience. Used by some of the biggest creators on the Web.

I love that it's totally dedicated to this proven, great business model, which is, have a business that has members that pay you to be members for. And then give them something of value. You know? It could be a podcast like this one. You could make a paid podcast. Why not?

You could be a paid newsletter. It could be educational content. It could be you're a comic book creator. Anything you could think of where you can provide value for members, Memberful is there to do it for you.

It handles all the hard stuff like taking money and doing the recurring revenue and all that stuff, allowing you to focus on what you do best, which is definitely the right way to run a business. If you're looking to add membership to your business that you have already, this is the perfect technology for that. You can launch a new revenue stream.

You already have the business. Add a new revenue stream. Get your brain thinking in that way. It's so great.

It integrates with the tools you maybe already use. You know I'm kind of a WordPress guy (a lot of times). Memberful works with that. It works with Discord. It works with Mailchimp. It's so great.

It is a literal technology here. If you're a big-time developer (like me), come on, they have a full-featured GraphQL API. They have Webhooks. They have OAuth. They have all that fancy stuff.

Then you are offering that to your users so they can log in and get access to the stuff they know need to get access for. There is this and so much more. It's really modern tech, you know.

You want to make sure it's really easy to sign up, so you offer Apple Pay. They've got that. It's very modern, very cool.

Get started for free. You don't even need a credit card. Head on over to memberful.com. Thanks so much for the support. So cool.

[Banjo music stops]

00:17:15

Chris: You all have been around, shaping the Web for a long time. Lots of books about Web development and all that stuff, and then have ended up at different roles but, from my eyes, still looking to affect the Web in a positive way.

Jeffrey, you ended up at Automattic, as you said. Pretty different role for you. You were kind of a solo entrepreneur for a long time. Ran studios.

Jeffrey: Mm-hmm.

Chris: But all that time were advocating for standards and all that stuff. I don't know. What's the trajectory now that you can kind of look back on those 30+ years of Web development stuff, and then why Automattic?

Jeffrey: Well, I'll tell you an answer you don't want to hear. After 30 years, I'm kind of like I've done Web design and development. Others will carry on this work. I'm not ready to retire and I'm not dead and I'm passionate about the uses the Web gets put to and about people having a chance to own their own content and publish their content and, basically, I'm still passionate about the Web as a democratizing force, which was the first time I made a website, the first time I saw a website was an ugly little website that someone made.

The first time I saw a poetry ring, right? Which for kids - kids - that was instead of a social -- if you had a poetry website where you published your cruddy poems and someone else had a cruddy poem website, and someone else had a -- you know, that you'd all ban together to link to each other in a sidebar, this new invention called a sidebar with links. Which I think ended up getting called a link roll or a blog roll because -- anyway.

But I still think that's--

Chris: That was a way of feeling connected with other people?

Jeffrey: Right.

Eric: Yeah.

Jeffrey: Finding stuff before search engines, before search engines dominated.

Eric: Yeah, this is pre-Google. Like Google didn't exist.

Jeffrey: Google didn't exist, not even as a gleam in the eye. So, I love Automattic because the products are about that, you know, like anyone can sell anything wherever they are. Anyone can publish anything. Obviously, there are caveats with any of that stuff because when I first saw the Web, I was like, "Ooh, any wonderful person who wants to share their passion and joy can now freely," and it also means like some of the worst people in the world (from my point of view) can publish like hatred, so that's an issue we didn't expect in the beginning.

But for me, I am now more in a people area. I'm not in HR, but I'm in something called talent where it's about shaping, helping to shape the experience of people who work at the company, build morale, and let people know about the company because I remember approaching Matt Mullenweg a couple, three years ago now and just said, "Hey, you have a terrific company, but nobody knows about it."

Even though he hired me, initially to do Web stuff, but now I'm doing that stuff, like letting people know about Automattic because, for certain kinds of people who are idealistic and also like to work from home or need to work from home -- mobility could be an issue -- it's a great place.

Chris: Yeah.

Jeffrey: Remote work, everybody is doing remote now, but Automattic has been doing it forever. It's on this really high level of we know how to make that stuff work. So, I'm very happy being there. I'm also happy having a paycheck.

Chris: What did you mean nobody knows about it? Only because people know WordPress but not necessarily Automattic? Is that--?

Jeffrey: Yeah. yeah. Right. Right. People know WordPress. They know Tumblr. But it's not like WordPress and Automattic joined. I think one reason I've had a career is because I was shameless about branding stuff. When I was first making websites all by myself, I would be like -- you know I would have my name in the footer of the website. It started with that, "Contact the webmaster," and that quickly became, like, you know, before I had a studio. It was like me, and that's embarrassing. A lot of people wouldn't do it. But here I still am, so that's cool.

I think we have shame about branding, but it's too bad. It's sort of what you all were saying before about advertising doesn't have to be horrible. In a way, I make this great stuff, but nobody knows how to find it. Nobody knows I make it, so I need to let people know.

In theory, advertising is not evil. In theory, it's just like saying, "Hi. I have a restaurant. Come eat." You know? It's really just that.

Eric: Yeah.

00:22:35

Chris: Just a little sidebar here. I’m curious what you think about anonymity. It seems like -- not to necessarily drag this down this weird direction, but it seems like in this new world of Web3 garbage, whatever that is -- I'm sure you can tell how I feel about it based on that moniker -- anonymity is almost required, like it's really weird to use your own name. But that's not necessarily a new concept. People have been using screen names forever.

Jeffrey: Right.

Eric: Yeah.

Chris: Chances are your AOL screen name wasn't Jeffrey Zeldman.

Jeffrey: Right.

Chris: We kind of use screen names, but I feel that same way too. I am Chris Coyier everywhere, and it has done a good job for me. How is that not obvious, though? How come people don't see that and be like, "Well, if you use your name, that you get to build on the brand of yourself for a long time"? It just seems very obvious to me.

Eric: I was just going to say it's a lot easier for us white guys to do that. I mean--

Chris: Well, that's a blind spot for me.

Jeffrey: Because we have white names?

Eric: Well, because we don't have to face the kind of backlash that women will face, that people of color will face.

Jeffrey: Sure.

Eric: That kind of stuff. If you're making it -- if you are associating yourself with your brand all the time, like I don't really get hate mail. Once or twice over the years, right?

Jeffrey: No. Right.

Eric: As opposed to--

Chris: Daily.

Eric: Women on Twitter who are like once or twice in the last five minutes - or whatever.

Jeffrey: Yeah. I don't get inventoried on my appearance by everyone who feels that they have an opinion. I'm sure there are people who look at me and like what they see, and there are people who don't. But they don't -- it's not even a consideration because I'm a guy.

Eric: It's not a referendum....

Jeffrey: Right, and I'm a white guy. Yep. Yep. That's very true.

But I did want to make this other point, though. My favorite filmmaker (at the time that I discovered the Web) was Alfred Hitchcock, and I was very aware how he had marketed his, like, everything about him: his profile, his drole sense of humor. And he did, like, grossly commercial stuff like had Alfred Hitchcock magazine. But the result was that he got to make the films he wanted to make, and I thought that's cool.

Then the other one, I don't know if you all remember this band, Weather Report, from the '70s. They were like a--

Chris: Heck, yeah. Jaco.

Jeffrey: Yeah, okay. And their keyboard player was named Joseph Zawinul. It was a South African name, but he just started calling himself Zawinul, like Cher. Before Madonna, before Prince, he was just calling himself Zawinul. I thought, "That's cool," and I'm lucky that I have the name Zeldman because that's a weird name. Not many people have it. If I'd been Jones, nothing wrong with that name. Fine name. But it would have been hard to go "A Jones production."

Chris: Yeah.

Jeffrey: But I was able to just turn my last name into a brand. So, if you have a moniker that's unusual, it might work.

Eric: It might work.

00:25:48

Chris: Eric, you've also been around a long time and wrote a bunch of books. You were the CSS guy, the original OG CSS guy, in a way.

And now have found you way, through zigs and zags, to at Igalia, which is super involved lately. Really, it has become a name that I think the company has probably been around a while, but it's become a bit of a household name lately, at least in the Web dev circles, for the amount of work that it gets done in browsers. Maybe its brand is getting better. [Laughter] That's what's happening.

Eric: Hopefully.

Chris: Yeah.

Eric: Yeah, Igalia has been around 20 years - 21, I think, at this point. I think last year was the 20th anniversary. But yeah, the browser work, in this field anyway, what's gotten them noticed, you know, doing CSS Grid, basically, like shipping it in browsers and other stuff. Focus Visible and WebKit has pseudo-class in Chromium is pretty much Igalia. That hasn't happened quite yet, but we announced intent to ship, so that's basically everything is in place for it to be turned on by default in a future release of Chromium. Yeah.

You can use it now if you have the experimental Web features flag turned on, which I'm sure all of us on this call do. [Laughter] You can use :has in Chromium as long as you've got that flag on. You can also use it in Safari without any flags because they actually managed to ship it first. Yeah, I've been playing with that. Yeah, Igalia does a lot of work.

Chris: Unbelievable, it's possible. I just think that alone would have just changed Web development. If we just had it all along, if it just shipped in CSS 1, it would just be a different Web.

Dave: Yeah. How many times, Eric, have you written the phrase, like, you can't select a parent - or whatever?

Chris: Yeah.

Dave: It's like, "Surprise! You kind of can now."

Eric: Now, 25 years later. Great.

Well, and the barrier was always performance. But given the speed at which browser engines can now operate, and also having done some fairly clever optimization of the tree walking, it is possible now to have performant not just parent selection but ancestor selection and beyond that.

I did a short video of the basics of :has. Sort of like a promo video for Igalia that's up on YouTube, but I'm currently working on -- as we're recording this -- I'm working on a longer one that gets into some of the more ... and convoluted stuff you can do with :has in conjunction with other things. It's not just, "Hey--"

You could literally say, "If this body, if the body element or the HTML element has something like this class or this ID, then change the styling of the entire document, like change the background color because it's the about, it's part of the about page." Right? It doesn't matter how far down that class or that ID is. It could be 17 levels deeper in the markup.

That sort of thing, the ability to have to look down the tree and then look back up the tree, was always the blocker. But in a very grossly simplified way, the way that :has processing is done is from the bottom of the tree up. Instead of starting from the top down and then having to loop back, it literally starts from the bottom up and flags elements as being selection candidates, so it drastically reduces the number of elements that have to be looked through from there on.

Now it's not to say that you can't bring a browser to its knees with :has. I'm sure that there are ways to do it.

Dave: Anna Tudor is working on that right now.

Eric: Yeah. [Laughter]

Dave: [Laughter]

Eric: Working on it. She's probably putting the finishing touches on a CSS-Tricks article of six ways to do it.

Dave: Yeah.

Eric: But yeah, that sort of thing is what's making :has possible.

00:30:22

Jeffrey: Eric.

Eric: Yeah.

Jeffrey: Eric, I have a question for you. It's probably fair to say that media queries needed to exist before Ethan could think of responsive Web design, right?

Eric: Yeah.

Jeffrey: It was sort of something that people had been talking about in different ways for a long time, but media queries made it possible. That was a huge industry-changing thing.

So, the thing you're talking about with :has, what new big design idea is someone going to come up with as a result of that? Is it an interactive thing?

Chris: I've been seeing that video game type stuff, that kind of like logical operators in being able to move controls around in CSS. Maybe not it alone but go ahead.

Eric: Yeah. I think one of the things :has immediately makes possible is -- and I'm going to use this as a pawn -- classless design. Not completely class-free, but you can drop so many classes, and you can drop a fair number of interactive JavaScript widgets.

An example here is in a different project I've been working on. Because :has isn't widely supported and hasn't been widely supported for a few years, I'm using JavaScript to do things like if this checkbox is checked, then add these classes in other places because I need to know over here. I'm using JavaScript to do this. I need to know over here that that's been checked over there.

With :has, I wouldn't have to do that at all. I could literally, at the body level, say if this body has this element ID checked, then apply these styles to these other things.

Jeffrey: Like animation might happen as a consequence of someone hitting a checkbox, in an example.

Eric: It could. Yeah.

Chris: Anywhere in the doc.

Eric: Anywhere on the page.

Jeffrey: Right.

Eric: For me, I even had to do it in this situation to make the little slider on the toggle work because of the way that the form and the label and everything was structured. It just made more sense to do it with JavaScript.

It was very light JavaScript. I wrote it myself. It didn't take that long. It's not like this huge library. But with :has, I could have just done it with that and not have to go to JavaScript, which I think is one of the keys of media queries leading to responsive Web design is that it made that responsiveness accessible. You could do everything in responsive Web design with JavaScript, but you had to understand (at a fairly deep level) browser windows in JavaScript, events, and blah-blah-blah-blah-blah. Media queries abstracted that away, made that very accessible.

Chris: Mm-hmm.

Eric: As a CSS author, you could just do your media queries.

Chris: What an interesting thought that you could do everything that media queries could do in JavaScript. It's just nobody did.

Eric: Right. Or almost. I shouldn't say everything because it was much more difficult to do the actual media-dependent things like, at this breakpoint in print, I want to do X. You could do the at this breakpoint, but the in print was really hard or perhaps impossible at the time -- I don't remember anymore -- to do in JavaScript. But the visual responsiveness was possible.

00:33:56

Chris: I wonder if it's because, at the time, there was certainly a lot more human beings that knew and wanted to work in CSS.

Jeffrey: Right.

Chris: I wonder if now the proliferation of JavaScript people, if that's less true.

Eric: Yeah, perhaps. But I think things like :has and container queries, which are also starting to land in browsers, are going to make all of that a lot more accessible rather than having to understand a JavaScript framework or write your own JavaScript to make those sorts of things possible. You'd just be like, oh, okay--

Jeffrey: Accessible to makers, not to the end user.

Eric: Right.

Jeffrey: Necessarily.

Eric: Yeah.

Jeffrey: Then that raises the question, which is more performant? Does :has put less of a load on the computer? Will it enable the website to be faster, or someone with a less powerful phone still get the thing, or you don't know?

Eric: That's not super clear. I don't think (at least initially) that :has will be significantly less performant than the equivalent JavaScript. But one of the things with JavaScript is, to make it really performant, you have to really know JavaScript. The JavaScript that I was just talking about a minute ago is probably not the most performant, but it has to do three things and so computers and browsers are fast enough now. JavaScript engines are fast enough now that I could bury my ineptitude under processor cycles, basically. [Laughter]

Chris: [Laughter]

Eric: I can not worry about it because I'm not looping through the document multiple times. But yeah, I don't know. I've seen some stuff.

... from Apple posted a video where it was like this table of hundreds of cells, or maybe it's just an array of divs. I'd have to go look at it again. But anyway, if you hover over any one of them (these tiny, invisible divs), it would create this pattern responsively to where the pointer is, and I don't even know if JavaScript would be that fast. I mean probably.

Chris: Canvas? That seems like Canvas....

Eric: They just did it with a bunch of :has selectors.

Chris: What?!

Eric: I just tried it in Chromium, actually, and it was slower. So, clearly there's optimization. There's plenty of optimization room, and that's the interesting part is that I think, over time, the CSS will probably become more performant because JavaScript engines have had now 15 years of massive performance investment, and so have CSS engines, but :has hasn't had that yet.

We'll see. It'll be interesting. Any time that you've been in a situation where you're like, "Ah, crap. I have to class something. I have to class the parent or something two or three levels up because of this thing here, like I have a little sale banner, so I need to class the div for the item to be sale so that I can style it differently," that goes away. You don't have to do that anymore. You can just have your little sale thing and then have a rule somewhere that says, "If the div of a class of shopping item has a thing where the class of sale inside of it, boom, style it." Done. I didn't have to change my markup at all.

Chris: Technically, it's probably more work for the computer, but it means that it's replacing some other piece of definitely slower technology. If it replaces any JavaScript at all, it's almost definitely faster.

Eric: I can't say that for sure.

Chris: Yeah.

Eric: But it's not going to be significantly slower.

00:37:50

Dave: It seems to me it maybe even replaces CMS hacks, templating hacks you had to do, like, "Oh, if it has a product, chuck a class way up there that says products one," because you're like, "Oh, if it only has one product, do this. If it has five products, do this."

Eric: Yep.

Dave: It feels like you unlock context, like contextual Web design.

Eric: Mm-hmm.

Dave: That's a book. I'm going to sell it on A Book Apart.

[Laughter]

Jeffrey: That's the next big thing, my friend. You just said it.

Eric: Contextual design, there you go.

Jeffrey: Contextual design.

Dave: But I think it's just like it unlocks this whole -- just the ability. We didn't have it.

Eric: Yeah.

Dave: You had to do tricks, and you had to do counts and stuff. But now you can just be like, "If it has LI Nth of type three--"

Eric: Mm-hmm. Yeah.

Dave: Or something. Maybe that's a bad example, but--

Eric: No. Actually, I think it's actually a good example because, if you think about it, a data table or list, you might want to style it differently if it's super long or if it's super short.

It's like, well, we have these lists but, every now and again, we have one that's three items or two items. Right?

Dave: Mm-hmm.

Eric: And so, let's make that a little bigger or let's space it out a little bit so it doesn't give -- like give it a little more margin so it doesn't get lost in the copy around it. You just do UL has not LI Nth of type three.

Dave: Mm-hmm.

Eric: That'll get you any one or two list item. If you want to take that up to five, then you have one, two, three, or four list item, item list, and then you add a little bit more margins, some block margins to that UL or that OL or the table - whatever it is.

Dave: Yeah.

Eric: Then everything that has more than that, everything that's longer doesn't get that extra block because it doesn't need it.

Dave: Yeah.

Eric: Yeah, absolutely that kind of stuff is possible.

00:39:50

Jeffrey: CSS hasn't attained singularity yet but this is my fantasy in the first edition of designing with Web standards, but I never explained it very well. I don't think anyone understood. But when I said rules-based design, the idea was that, oh, this is what it looks like if it's a business card. But if it's a shorter name or if it's a long Spanish phrase, then the design reconfigures itself. Which in a way, CSS Grid (in some ways) let's you do that.

Eric: Being able to size things. One of my favorite tricks recently is max width, max content, which basically means don't let the box get any wider than the longest bit of content. But since it's a max width, it's not forced to be max content. If you come out to 100% the size of the container, then it starts wrapping the content.

Short content, like the box is just around that content, but long content, it wraps multiple lines and you get a box that surrounds it. You don't even -- you can do that right now.

Chris: Like the table used to do.

Eric: [Laughter] So you know.

Jeffrey: Yeah, that is what table used to do.

Eric: Kind of, yeah, except you can do it to anything. Do it to your H2 so that you put a border across the bottom of your H2s or your H1, or whatever.

Chris: Then it just stops right there.

Eric: It'll just stop at the end if you have a two-word H1. But if you have this super long H1 that goes multiple lines, then it'll just be across the entire width of the element box.

Jeffrey: Like widow control, we still use JavaScript to do that, correct? Last time I checked.

Eric: Yeah, widows and orphans are not really supported. CSS had property. I guess still does. But they're not really well supported, and they were only ever about lines of text. They weren't about individual words.

Yeah, doing the thing like having JavaScript that runs through your content and replaces the last space in every paragraph with a nonbreaking space so that it always keeps at least two words, you still need JavaScript for that. But I mean with everything else CSS is doing now, it's like container queries, cascade layers, grid, paths - all this stuff is dropping. Maybe it's time to go back and say, "Hey, can we have line orphans or orphan words or some property?"

Jeffrey: Right.

Eric: That'll let us do that where it'll basically say, "Keep the last few strings of text together at all times." Maybe. I don't know. Why not?

Chris: It's really a curse to care about that.

Jeffrey: Yes.

Eric: Yeah.

Chris: Like the first ... that you learn that. You're like, "I'm going to spend the rest of my life putting NBSP at the end of two words."

Eric: Yeah. It's like teaching someone to recognize bad kerning, and you've cursed them for the rest of their life as they go about their--

Chris: Yeah. It's all over.

Eric: As they go around the world, and they see a sign that somebody tacked up on a door that they printed out. You're just like, "Ugh! No."

Chris: R/keming, don't subscribe.

Eric: [Laughter]

Jeffrey: I was lazy. One of the reasons I think that I got involved in Web standards early is because I was lazy. I was like, "I don't want to learn five ways to do this. This is too hard." To me, Web standards is working when it makes it simpler. Right? Then we can focus on the content instead.

Chris: I like that.

00:43:04

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Notion. Learn more and get started at notion.so.

It's this wonderful app that I couldn't possibly recommend more to use for essentially writing documents. But it's so much more than that. It can be a place for your Kanban boards, for project planning, and meeting notes, and calendars, and notes of any kind.

You know a little side thing I see people doing a lot is writing out a quick document, which will look beautiful because Notion looks great. Making it public, and then using it as like a job posting website, like a quick way to get a URL to share with the world that says, "Hey, we're hiring!" That kind of thing.

Their sharing model is so great. At any given page, and it can be nested as deep as whatever, you can kind of just mark as public, a little toggle switch, and then share that with anybody who wants to see it on the Internet. But what's cool about that is it doesn't have to be totally pubic. Another way you could do it is type in an email address and invite somebody to the document (either just to see it or to have write access to it and collaborate with you on it). It's a great collaboration tool in that way.

For example, we have a show calendar for this show. We invite collaborators (even from outside the ShopTalk Show organization) to collaborate on the calendar -- like our editor and our sponsors and stuff -- so we can all have this shared understanding of what's happening with the show. Notion really enables workflows like that. It's so cool.

Thanks for the sponsorship, Notion. That's notion.so.

[Banjo music stops]

00:44:40

Chris: We've mentioned the word performance a couple of times, and I think this is almost a merciful thing of CSS is that there's already so much, an ever-increasing amount of performance stuff to talk about. In fact, I almost have a correction we should make (last week), but I think I'll save it for an episode about some new Google metric that they emailed us about, like, "You got it wrong," kind of--

Thanks, Jeremy. We did get it wrong.

Dave: Whoops. [Laughter]

Chris: [Laughter] A little bit.

Dave: Ka-ching!

Chris: Not our explanation, but the fact that it's a core Web vital. It is not.

Okay. There were ten asides before I even got to the point.

There's all this stuff like make your files smaller and use less JavaScript and defer loading of things. There's just a million things to think of. It's a job in itself. Mercifully, we don't generally think about how performant is this piece of CSS.

In fact, it almost became the mantra, like, don't worry about that. Do not let that seep into your brain. Do not worry that a star selector is slow in CSS because there's a minute where it's like, "Yeah, but that selects everything on the page, so that must be slow."

Eric: And there was a minute where it was.

Chris: The vibe became, like -- oh, yeah. [Laughter] Okay.

Jeffrey: Right. Right. That's why you wrote -- Eric wrote the -- what was it called? The reset.

Eric: It was the reset.

Jeffrey: The reset.

Eric: Yeah.

Jeffrey: Because it wouldn't--

Chris: Didn't use star?

Eric: Right.

Jeffrey: Because you can't -- right, instead. So, he's like, "Here are all the possible rules." Okay. I normalized everything. At the time, right.

Eric: Yeah.

Jeffrey: If you just hit star, the browser would still be trying to render.

Eric: Yeah.

Jeffrey: Now.

Eric: [Laughter] Yeah. Right. But yeah. But that kind of quickly went away, like you were saying, Chris. Then we had to have that sort of reverse education campaign. It was like, "Don't use star."

Chris: Yeah. Right.

Eric: It's too slow. Then, okay, remember when we said don't use star; it's too slow? It's not too slow anymore. You're fine. Go ahead. Use it. [Laughter] Right?

Chris: Right. Right. It stayed that way for a long time. But now :has threatens it almost, or does it?

Jeffrey: It's like the period in Web standards when people thought it was bad to use tables, even as tables, because we'd done such a good job of telling them, "Table ... is bad. Use CSS."

Eric: Yeah.

Jeffrey: That they thought, like, tables are fine for tabular data, but everyone was sort of like, "Look, I made this CSS and it's all divs." ...use....

Chris: That all got corrected. "Tabs are for tabular data," is almost a T-shirt now.

00:47:11

Eric: Okay, so I would not say that :has threatens all that because here's the deal. Browser engines will not accept something that threatens their rendering performance.

Jeffrey: Yeah....

Eric: If they accept something into the engine, basically what that means is they are confident that, in 99% of cases, it will not threaten their frame rates because browsers are just like anything else on a computer. They have to maintain their frame rates, and browsers do their utmost to maintain 60 frames a second or more, which is like the standard for a first-person shooter.

Dave: What did you call it? The 60 FPS--

Eric: First person scroller. Yeah.

Dave: First person scroller. [Laughter] Yeah.

Eric: Basically. But it sounds like some kind of, "Oh, I'm going to take two unrelated things and put them together and it'll be funny." No, they're not unrelated. That's the thing. Browsers literally are supposed to render at 60 frames a second or more. If you, if we, if anybody tries to land a patch that will drop the common performance below that threshold, they won't take it. They just won't merge it into the code base. It won't ship. So, :has does not--

Chris: Certainly, with CSS, right? But there's all kinds of JavaScript crap, like At Event listeners scroll, you know?

Eric: Sure. Yes. Like I say, I'm sure there are ways that you can use :has, like abuse :has, to make a browser be slower. In fact, I saw one recently. Well, that thing I was talking about that ... did where you hover and it creates these patterns using a bunch of :hases. It's quite a bit slower in Chrome. Okay, but that's not going to stop them because that's very clearly a stress test. It's not something that someone is going to do for a design. Yeah. It doesn't really have a design need, and it also shows them, "Well, here's a place where we could look at how to make this better." Right?

I'm not concerned about that, again, because if the Chromium team put a patch for :has, basically puts this code through whatever their tests are, and it drags the browser down too far, they won't ship it. Apple has already shown with Safari that you could do this and not bring the browser down, so I'm pretty sure it's going to happen.

The same thing with container queries.

Chris: It's actually a really nice example of browser diversity being good because if Apple did it, they can drive that jealousy of Chrome and be like, "Oh, they did? Crap. I guess we better get on it and figure it out."

Eric: Yeah.

Chris: Whereas if there was only one browser, there'd be no motivation. They'd just be like, "Nope, it's too slow." There's no other team, that there's no--

Eric: And to a certain extent, that dynamic is what caused Apple to ship :has first because Igalia had been working on :has in Chrome and been going through this process and was on this path of getting to intent to ship, and Apple managed to drop first and claim the bragging rights, which more power to them. You know? If that's what they can do, then that's what they do.

The same thing. It looks like it's kind of the same thing with container queries. Igalia is not, I don't believe, working on container queries, but Chrome is. Right? The Chromium team is. It looks like the WebKit team did something similar. They're like, "We could probably get something in there ahead of them. Why don't we do that?"

Chris: People love an honest fight.

Eric: Yeah, this is why I love browser diversity, and I wish we had more of it for that very reason.

00:51:04

Chris: Fantastic. Right after we booked you two -- Dave, you pointed this out -- ateventapart.com/news there is a "Looking Ahead Insights" from Jeffrey Zeldman and Eric Meyer where you both kind of wrote up where you thought it was going. Did you want to touch on any of that?

[Laughter] I like Jeffrey is like, let's make humanism, democracy, and inclusion the real Web 3.0. That's a classic.

Jeffrey: Thank you. There you go.

Chris: ...writing ending.

Eric: I'm down with it.

Chris: Yeah. [Laughter]

Eric: And I wrote about cascade layers because I'm always the Spock to his Kirk, as we've said for years.

Chris: [Laughter]

Jeffrey: Right.

Dave: [Laughter]

Jeffrey: Yep.

Eric: I'm always in the technical weeds, and he's like--

Jeffrey: Again, because I'm lazy.

Eric: Hey now.

Jeffrey: No. No, because I'm like, "How can we simplify this so I can do less?" When we talk about widows and orphans, I can remember a period of telling my clients, "No, you can't do that in a browser," and enjoying that.

[Laughter]

Jeffrey: They'd go, "I want anal subatomic control. I want, to the micropixel, absolute control in every browser on any--" and I'd just go, "Yeah, can't do it."

Chris: You'd love PDFs.

[Laughter]

Eric: Yeah, exactly.

Jeffrey: Yeah. Right. Right. That's called a book. Here.

Chris: Yeah. [Laughter]

Dave: Books are still cool but might not get as much attention on the Web.

Jeffrey: Right. it's weird because one of the things that drove design, Web design, in that ten years was book esthetics.

Eric: Yeah.

Jeffrey: Maybe in the last 15 years, right? People were like, "Yeah, we should really control our margins." A lot of CSS was driven and improvements were driven by -- I mean it goes back to people like Dean Allen back in the day just going--

Eric: 4.1.0.

Jeffrey: Yeah.

Eric: Yeah. Dean Allen, rest in peace.

Jeffrey: Rest in peace.

Eric: Yeah. I mean they say every new medium apes the medium it's built on or replacing.

Jeffrey: That's right.

Eric: Yeah, that's where a lot of that came from. Art directors who were used to--

Jeffrey: And Flash. Yeah.

Eric: We're going to paste it up on the board, and then when it gets printed in the newspaper, it's going to look exactly like that, or whatever. Right? Once we've shot the video, it goes on everybody's 4x3 TV screen, and maybe some people will be in black and white, but we just accept that that's the case. Everybody gets it in color, and it's in the same aspect ratio. Yeah, at first and for a long time, the attempt to recreate that on the Web--

Jeffrey: Yeah.

00:53:44

Eric: John Alsop (in 2000) told us that we were wrong on A List Apart.

Jeffrey: Right. Don't.

Eric: Yeah. He was like, don't.

Jeffrey: Right.

Eric: It's a new medium. Treat it as such.

Jeffrey: I took that to heart. I took that to heart. Yeah, don't.

Eric: Yeah. Not nearly enough people did, though. That was the problem.

Jeffrey: But the people that stubbornly said, "No, I want that," ended up driving a lot of innovation that we enjoy now.

Eric: That's true. Yeah.

Jeffrey: We needed people like John saying, "No, that's silly. Don't do that. It's a new medium." And we also needed people like Jason Santa Maria going, "I want this to look as good as this book," and, as a result, finding ways to do it.

Eric: That's true. That's true.

00:54:24

Chris: It's funny you've got learn the same lessons over and over. I have a truck, and I plug my phone into it. Apple Car Play comes up. It looks great, right? That's how I get around. I have my maps on there.

I rented a van the other weekend, and it has a long display over the radio. It's a really, really wide thing. It's like a Mercedes, and that's how they roll. I plugged my phone into that, and it just has big, giant black bars on the side because Car Play just has a rectangle that it ships in.

Then it was cool to see their release at WWDC. Now it's aware of the fact that cars have different-sized displays in them, and it rearranges itself to fit in there. You're like, "Welcome to 20 years ago."

Jeffrey: We've taken pity on the Mercedes truck owner. The poor Mercedes truck owner.

Chris: [Laughter] Finally.

Jeffrey: With your ultrawide display, with his latte in his cup holder. That poor devil.

Eric: It's responsive.

Dave: That's the humanism you were talking about.

Jeffrey: That's true.

Eric: Yeah.

Jeffrey: That's true.

Eric: It's a responsive dashboard design. That's what it is, basically.

Jeffrey: There are no edge cases.

Eric: It'd be fascinated to know how they are managing that. Are they using effectively media queries? What are they doing?

Jeffrey: It's :has. It's :has.

Eric: I would really like to know.

Dave: [Laughter] Can I also expense a new Mercedes as a testing device?

Jeffrey: Absolutely.

Dave: [Laughter]

Jeffrey: I like the way you think. I like the cut of your jib, sir.

Chris: I mean there's already precedent for it, right? There are already iPhones with pretty different screen sizes, and they have different number of rows of things. It's whatever technology they employ for that, theoretically.

Eric: Yeah.

Chris: Probably not CSS.

I was going to ask you if cascade layers makes anything simpler, but it probably does. [Laughter]

00:56:14

Eric: Yes, it does.

Chris: It doesn't appear to (on the surface).

Eric: Yeah. I mean I don't want to get into a huge thing, but I had an interesting thought the other day and a short, little Twitter conversation, very short Twitter conversation with Jeremy Keith. If you go back to the original CSS proposal, not the specification but the cascading HTML style sheets document that was written by Holcomb Lee in 1994, the syntax was very different. I'm just going to say. It looks more like JavaScript than it does -- and this is pre-JavaScript, so he wasn't copying JavaScript. But it looks kind of like JavaScript. It was like h1.font.size=12point was what the syntax looked like.

But -- and this is where this is going -- you could also assign an influence weight to every rule. You could say h1.font.size=12point or 24 point 30%. Then somewhere else in the style sheet it would say something like h1.font.size=36point60%. Okay?

Chris: I hate it. [Laughter]

Eric: Well -- but think about it. There are a couple of ways to resolve that.

Chris: Yeah.

Eric: One is to do complicated math to be like, "Okay, well, if we take 36 point at 60%, and we take 24 point at 30%, we end up at like 25.7 point," or something.

Chris: [Gasps]

Eric: That would be possible, or you could just say, "Well, this one is higher than this one, so this one, like the 60% wins over this 30%." Right? That would be the much simpler way to do it and probably how it would have ended up if that had come through. But cascade layers lets you--

Dave: It's the sliding Fs scale. How many Fs do you give about this rule being applied? [Laughter]

Eric: Yes.

Jeffrey: Hmm.

Eric: And in fact--

Chris: Watkins for CSS?

Eric: In fact, at the end of that proposal, in ASCII art, there's a slider. There's ASCII art sliders for various things. The idea being that you can take this rule. You can shift whatever. Anyway--

But cascade layers -- this is the point -- kind of lets you do that. You don't get to assign them percentage weights but you get to say what order they come in. So, this rule for H1s sits in this layer, this font sizing rule for each one sits in this layer. If there's a layer that has more precedent, then that role for H1 font sizing will win over the one in the lower layer even if they have different specificities.

So, the cascade layers become like -- we've always worked with cascade layers. There were two. There was important, and there was everything else. Those were the original cascade layers: important and default. Right?

This is just letting you set up more cascade layers between those two. And if a rule, let's say in the page cascade layer, tries to set something and there's a rule for the design system cascade layer, no matter what the specificity of the rules is, no matter how many selector classes, IDs, doesn't matter. The one in that page layer, if it's higher than the design system layer, will win out.

Chris: It will win.

Eric: Yeah.

00:59:37

Chris: Yeah. The whole beast. The whole selector becomes irrelevant. Doesn't that scare you to teach CSS? It used to be like, "IDs are strong," and now it's going to be like, "IDs are strong in the layer that they're in."

Eric: In their layer and compared to every layer underneath them. Yeah, it will complicate things but, at the same time, it lets you do a thing like, here's the style sheet for the design system. We're going to import it. On the import, we're going to say what layer it's in. It's in the design system layer, the atomic layer, whatever layer, whatever you decide to call the layer. You can call it Steve - whatever.

But then the page, you can say, "Okay, everyone on the page is in this layer," and so you can very selectively override things about the design system, like the page title on this page needs to be maroon instead of navy. It's navy in our design system, but on this page it needs to be maroon.

Chris: And, crucially, I don't give a crap about the selector.

Eric: Exactly.

Chris: I don't want to overthink a selector.

Eric: I don't have to go into the design system and be like, "Okay, what's the specificity of the selector?"

Chris: I could just say H1s are maroon, and it would just win against everything else.

Eric: Boom! Done. Yep.

Chris: That's whack! [Laughter]

Eric: Yep. It's a new way of thinking about it. But it takes from design systems because one of the design principles of design systems (or good design systems) is they should be easily override-able.

Chris: Hierarchical action?

Eric: Yeah. It should be easy to override.

Chris: Glad somebody smart thought about it. It seemed to happen awfully fast. You used to have this -- you know, Dave has got this slow like brisket concept that's like--

Eric: [Laughter] Yeah.

Dave: --sometimes slow is good on purpose. You know?

Eric: Yeah.

Jeffrey: Definitely.

Chris: If we get too fast, if we get too fast with Web standards, it'll be like, "Did we super think about that at all the way?" [Laughter]

Eric: Well, cascade layers have been thought about for a super long time. Yeah, cascade layers have been thought about for--

Chris: Yeah. Yeah. I get it.

Eric: --possibly 20 years now. [Laughter] I'm not 100% sure, but the implementation did happen very quickly. You can use cascade layers right now in pretty much every browser and have them work. We're just not--

The thing you have to watch out for is, because of the way the syntax works, anything in a cascade layer block will get ignored by older browsers, like completely ignored by old browsers. So, we're right now in that transition phase that we used to be with media queries where it was like, "Well, you've got to be real careful with your media queries because older browsers will literally not see anything in your media queries." Right? Anything that you need all users to see can't go in there.

We're in that same kind of space with cascade layers right now, but yeah, it will make a lot of things simpler. And I think one of the reasons that it dropped so fast in so many browsers is that browsers were already maintaining layers. They had important and default. All they really had to do was figure out how to slot user or author-defined layers into that hierarchy, and apparently, it wasn't that difficult. I mean I'm sure it wasn't trivial, but it apparently wasn't that difficult because it was almost like Grid all over again. It shipped in every browser in the space of a couple of months. It was amazing.

Yeah. Once a spec was agreed upon and basically minted, everyone was like, boom, done. Wow. Cool.

01:03:03

Chris: Well, let's wrap it up, Dave.

Dave: Yeah, we can wrap it up. Thank you all, both, for coming on the show. We really appreciate it. We are looking forward to An Event Apart Denver, so that should be exciting. But for people who aren't following you and giving you money, how can they do that? We'll start with Jeffrey.

Jeffrey: You don't have to give me money, but you can find me at zeldman.com. You can always -- I'm always putting out A List Apart - very slowly. It's like the opposite of CSS-Tricks. They're both wonderful, and CSS-Tricks is like, "If you miss even like two hours, you probably missed something really cool," and A List Apart is like, "Come back in a month. We're slowly digesting this meal." No, I guess that's a bad metaphor. Don't -- no, that's a really bad metaphor. Forget that.

[Laughter]

Jeffrey: But slow, it's slow, and I'm @zeldman on Twitter, and that ought to do it.

Eric: I'm kind of the same. You don't have to send me money. Jeffrey and I have been doing this long enough that we both came from the ethos of you give back, and also have been fortunate enough to be successful enough that we never got around to the, like, pay us money thing. But you can find me at meyerweb.com and on Twitter and GitHub and various other things. My username is almost always @meyerweb. If it isn't, then I probably don't use that network, so don't worry about it. [Laughter]

Dave: And if you have an Oculus, pick up Eric's new browser, Wolvic.

Eric: Yeah, it's not mine.

Dave: Enter the metaverse.

Eric: That's Igalia's. I just write about it.

Dave: Nuance there, but-- [Laughter]

Eric: Okay, yes. Nuance.

[Laughter]

Eric: Just a tiny little -- it's an obscure point.

Chris: It's a collective, isn't it?

Eric: I will admit I have landed a patch in Wolvic.

Dave: Hey!

Eric: I fixed a grammar error in one of the preferences. [Laughter]

Chris: [Laughter]

Jeffrey: Yeah....

Eric: That's my patch.

Jeffrey: Yes, I've contributed to WordPress in much the same way.

Eric: Yeah.

[Laughter]

Jeffrey: Yeah.

Dave: Oh, wonderful. Well, thank you all so much for coming on the show.

Eric: Yeah.

Dave: 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 16 tweets a month. We have youtube.com/shoptalkshow. And join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

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

Chris: Yeah. Next time, we'll explain to you kids what Eudora is. I saw that.

Dave: [Laughter]

Chris: ShopTalkShow.com.