602: What Does Accessibility Really Mean?

Download MP3

Voiceover pays us a visit, we talk about what accessibility really means, the difficulty of closing a dialogue element, web components at work, and jQuery 4 is out.



Chris Coyier and Dave Rupert in silly sunglasses and a sign that says Shawp Tawlkk Shough DOT COM

Chris Coyier and Dave Rupert

This episode is with just Chris & Dave, ShopTalk Show's hosts. Chris is the co-founder of CodePen and creator of CSS-Tricks, and Dave is lead developer at Paravel.

Episode Sponsors ๐Ÿงก


[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the shed--Rupert. With me is Chris--in the office--Coyier. Hey, Chris. How are you doing today?

Chris Coyier: Oh, I'm doing great. Thanks, Dave. Have a jampacked week of news, I think.

Dave: Yeah. I was just going to say. Oh, hold on.

Chris: Yeah?

Dave: Somebody is here, Chris.

Chris: Oh, my God.

Dave: It looks like a floating--

Chris: Forgot to lock the door again. Unbelievable.

Dave: --cube. Oh, crap.

[Unintelligible digital voice]

Dave: [Speaking in a digital voice tone] Hello, Christopher. It is me, voiceover. I hope you are having a wonderful day.


Chris: Wow. Interesting. Are you AI-powered somehow or who am I talking to?

Dave: [Speaking in a digital voice tone] It is me, voiceover, the screen reader. I have, list, three items, questions for you if you have time.

Chris: I suppose. So, you're buddies with Siri, or are Siri - or whatever.

Dave: [Speaking in a digital voice tone continues] Next ... one.

Chris: [Laughter]

Dave: It is almost the human holiday of Valentine's Day. Why does no one love me or pay attention to me?

Chris: [Laughter] Can't help you with that, voiceover. It feels like you're just reading something that somebody else wrote, though, so I worry about their feelings.

Dave: I live a lonely life, Christopher.

Chris: [Laughter]

Dave: People only turn me on occasionally.

Chris: [Laughter] Yeah. Yeah. And they turn up your speed sometimes too, don't they? So, what's your...?

Dave: I can talk very fast. Okay, something I can do.

Chris: I'm impressed by your ability to not just go to bullet point two, though. You know? You're....

Dave: List item two.

Chris: [Laughter]

Dave: A lot of people in the abbreviation A11Y accessibility community are burnt out. Do you think that is my fault?

Chris: [Laughter] No, I don't think it's your fault. I think it's, yeah, a lot of years of gunning for the same goal without affecting much change, unfortunately. But fortunately, AI is here to fix all accessibility problems, too. A lot of people companies that make these overlay products got a lot of gumption. I think they're going to do it.

Dave: That leads me to list item three. I read an article this morning over on, link, http about AI and accessibility by Aaron Gustafson. I know I am a robot, but is AI coming for my job too?

Chris: [Laughter] No, you're just a speaker. I think you're going to be okay. Very interesting article, though. I wish the best for you. Anybody that needs you to read out the alt text of images, boy, they're still going to need you, so know that you're loved, robot.

Dave: Thank you for helping me with my existential crisis. I will leave now and put Dave back on the microphone. Thank you. Good-bye.

[Unintelligible digital voice]


Dave: [Speaking in his normal voice] Whoa! That was--

Chris: Yeah.

Dave: Wow!

Chris: It's not every day you get to speak to the voice in the... the ghost in the machine.

Dave: You get to speak to actual voiceover on the podcast. That is maybe the first of its time. [Laughter] You know? That's great.

Chris: Yeah.

Dave: That was great.

Chris: And they came to your office, too, which is--

Dave: Yeah. They floated in, a little like sentient cube. I don't know, but it floated in.

Chris: Yeah, you think of these things as software, but they are hardware.

Dave: Yeah, somewhere. Somewhere, someone is... Yeah. Well, that was... Yeah, so, what'd you all talk about? Accessibility, probably. [Laughter]

Chris: Yeah. Yeah, yeah. About Aaron's article here. You know it was a lot of, like, what if computers could do AI accessibility? And it's like, I don't know. What if?

I guess it's worth experimenting with, isn't it? I mean I think people were mad at the overlay companies, and rightfully so because of the big promises and money getting slung around. Being like, "You're going to get sued, right? Well, then come to overlay corp. incorporated where we'll solve all your problems. It just costs money, dollars."


Dave: Mm-hmm. "And we'll also sue you if you just talk bad about us." [Laughter] But anyway... yeah. So, yeah. It's weird that accessibility is turning towards the... there's been a lot, like Mike Paciello from The Paciello Group, very well-known.

Chris: Oh, I heard. Didn't he... he's like, "We're the... I'm the CTO now at overlay corp."

Dave: Yeah. Yeah, at AudioEye, I believe.

Chris: How do you do that? Is that selling your soul to the devil? What did they give him, 1.5 a year or something? How do you get that? Or is he a true believer?

Dave: I don't know, man. It's sort of like a small shock. I don't know. It seems like maybe... Have you ever--? Did you ever see... watch Silicon Valley, the...? [Laughter]

Chris: Sure.

Dave: There's that episode where they're talking about the platform or the box - or whatever? Do you remember?

Chris: No.

Dave: The one guy, Richard, wants to build the platform, like the middle out compression platform. And he's just like, "I want it to be a platform where people can--" I don't know. They're just talking about platforms.

And then the sales dudes are like, "I need a box. Put it in a box, and I can sell the box." You know?

Chris: [Laughter] Yeah. Yeah.

Dave: And so, I wonder if we are having that moment in accessibility where it's too hard to sell the idea of having an accessible website, an accessible platform. People just want the box to - whatever - scratch that off their list that they did an accessibility for - whatever - tens of thousands of dollars a year in enterprise contracts.


Chris: Yeah, maybe. I mean it has come up over and over and over. We even talked about it with Brad last week. Here's one problem that can happen on a website:

There is a label. There is an input. And the label needs to be associated with the input. And the label is what gets read out to somebody who might not be able to see the label or they've focused on the input and they need to know what to put in the input.

It might say something like, "First name." And if it doesn't say, "First name," you have no idea what to put in that input. Right?

Dave: Yeah.

Chris: It's a classic failure. It happens all the time on websites. Just constantly.

Brad things a solution to that is a reusable component. You can never have this mistake if you use the input component in this design library because you can't. You get both elements at the same time. In order to use the component at all, you have to have a label. Cool. Problem solved.

Overlays presumably have some kind of way of fixing this. Accessibility testing companies want to just throw up red flags wherever they can for you, in CI, in your code editor or something. A lot of people trying to fix this kind of problem.

AI could be another solution to this problem. Where is it built in? Unclear. Maybe it's built-in right to your browser. It sees, "Ooh... wow. An unlabeled input."

But, hey, good thing I'm an AI model and I'm trained on the entire Internet. I think it's first name (based on a billion other patterns I've seen). Maybe I'll just fix it on the fly.

Is that good for the world? Probably.

Dave: That's what I... Yeah. I think so. For me, I think I'm coming towards probably like a larger theory of AI, if that makes sense. But I love it when it helps people become unblocked. Does that make sense?

So, if I'm using a screen reader and I hear "image," and it's like, "What is that? Tell me what that image is." Empower people to be like, "Make this image look like my thing," or I think, in the past, we've used an example of, "Well, if I'm color blind, AI, can you just fix this website for me? I just need you to fix this."

I think that human empowerment story is pretty good. I do think it does create a situation where we're putting a lot of trust in robots and the result is no one is ever going to make an accessibility website because we put it the onus on the person to solve their own problems for them rather than us just presenting a good default.

Chris: Right.


Dave: I just read a story on The Verge. Did you read that? A very beautifully art-directed story about AI and sci-fi writing. Just 100% up my alley.

Chris: Right.

Dave: It's art directed. It looks like an old, two-bit Macintosh. It was really great, You know I love it. [Laughter]

Chris: Heck yeah. You were just sharing a post yesterday over the... It was also randomly AI-related, right? It's based on some teacher who really wanted to incorporate--

Dave: Yeah. Yeah, there's another one about a teacher, right? And so, this one was about this author who is in the Amazon funnel, right? And so, they have to write ten books a year. I think every 49 days or something, they're publishing a book, which that's insane to me. But I guess if it's your job, you can do it. But that person, that author has data.

If somebody waits more than two months for my book, they'll just unsubscribe from my articles and leave forever. Which that seems like a little too capitalism. I don't know. People just being greedy. But I think they're on this--

Chris: It gets reductive, too. I mean George R. R. Martin can publish a book whenever he fricken wants to and people are going to read it. You know? They've been waiting for years and years and years. They'll keep waiting.

Dave: Yeah, but these books are probably - I'm going to just say - on the side of low quality, if that makes sense.

Chris: Oh, it does.

Dave: I hope I'm not judging. I think you can read trash. [Laughter] Trust me. You can read trash. That's great. But I think it was sort of in the Amazon unlimited realm where you get a free book if you read this or if you subscribe, you get a book, you get a cut. It's sort of like making YouTube videos.

So, this author has to put up ten books a year. She started using AI to write the books because it helped her get through the block. And if you've got to piece together a book in 49 days, man, if you're blocked on one day, you've severely harmed yourself.

Chris: So, that's where you're going with this. That block day, you feel like just gets its butt kicked by AI because AI can unblock it because you just -- I don't know. Maybe you just type in what you've got so far and ask where it would go from here.

Dave: Yeah.

Chris: Have it brainstorm some new characters for you or who knows.

Dave: Yeah, there was... Oh, I forget the name of it. In that article, The Verge article -- we'll put a link in the show notes -- there was a mention of an app that does this, writes AI stories for you.

The whole pitch for it is it never runs out of ideas. So, if you get blocked, this thing doesn't. This thing just has infinite ideas.

Chris: Yeah.

Dave: It just can generate infinite ideas. And so, that was interesting. I like that. I like that for unblocking people.

But the story goes on to say this author starts writing a story and slowly and slowly just starts yielding to AI to do the things. And then the author can't even remember the story that they're crafting. They're two, three chapters in, and they don't know who is doing what because they--

Chris: Because their brain didn't come up with those ideas. Something else did.

Dave: They didn't come up with it, so they didn't do the dialog. They don't know any story beats.

Chris: Yeah.

Dave: They can't remember the story beats that have happened so far.

Chris: That's bad, right? [Laughter]

Dave: That's bad now, right?

Chris: Yeah, I would think so.


Dave: And then there's another correlation. My brain is just doing correlations. I think that's either ADD or mild dyslexia. I'm not sure. I'm still figuring that out.

There's another one where Copilot (right)... Copilot came out; 55% more productive developers. Boom, boom, boom. Well, there's a new study that shows... And it's sort of a small sample size, but 40% of code that goes out through Copilot is reverted within the next 2 weeks.

Chris: What?

Dave: So, Copilot writes code, people put it, and then it's not dry.

Chris: Wow.

Dave: So, it just gets yoinked out again. Interesting, right? It's a cool unblocking tool. But it also has consequences, big consequences. And so, I wonder if the consequence for AI in accessibility -- tying it all the way back -- is, we'll just write websites and just assume AI will fix it, and then we won't produce accessible websites because we don't know how.

Chris: Oh, I see. Maybe if we happen to, and I'm not saying I'm on this side, but we say, "You know what? I think the world would be a better place if AI got involved with fixing accessibility problems on websites on the fly." Let's say that's where we came down, and the rest of the world kind of agreed and whatever Aaron is working on at Microsoft or whatever starts to see the light of the day.

Well, the long-term implications of that is we just get a lot lazier. We just absolutely stop caring about crafting an accessibility website from scratch just because we know it will be fixed.

Speaking of analogies and all that stuff, I think about - I don't know - it's like if your kid never has to clean their room, then they're never going to clean their room - or that kind of thing. You know?

Dave: Yeah.

Chris: There has to be... [Laughter]

Dave: Yeah. Yeah, yeah.

Chris: There has to be some kind of reason to do it. Yeah, that's interesting. Or even another one, like the NFL one where they get stronger helmets so they just hit harder - or whatever.

Dave: Hmm...

Chris: You adjust to what you have available to you. Or the performance one where the Internet gets faster so we just throw more crap at the Internet. We just tend to adjust to what we have available to us. And if accessibility becomes somehow "solved," then be damned if we're ever going to test for it again. Not that we do now.

Dave: Right. Right. Yeah, I guess, what is the adaptive--? [Laughter] What is the accessibility in this adaptive world where we've adapted to AI fixing all our problems?

Chris: Mm-hmm.

Dave: But that said, I think people should have that. If you show up to Best Buy and you can't buy a computer or you can't buy a washing machine -- I don't know why Best Buy sells washing machines, but they do.

Chris: Absolutely they do.

Dave: And you can't do that because they made the website bad. Yeah, I want people to have a little machine or browser extension that can just go fix website. You know? Or "Hey, Siri. Go fix the website." That would be cool.


Chris: Yeah. A big one from the article is the alt-text one, which I think a lot of us can wrap our minds around that, like, "Oh, man."

Dave: Yeah.

Chris: There's a lot of missing alt text on the Web. And you know what? Straight up, raised hand, I screw that up all the time because I'm just not thinking about it that much. I'm thinking about my experience of reading my post as I write it and not everyone's experience.

Dave: Mm-hmm. Mm-hmm.

Chris: And so, I'll just miss it sometimes. I just won't. I'll publish a post with an alt="" in that....

Dave: Right.

Chris: You know? And that's a total miss. And it's like, but that seems like low-hanging fruit. A lot of us have experienced what AI can do with image generation and describing images and stuff. That was early last year. We were like, "Wow. Look at how good it is at that." Why should that alt="" be sitting there when a browser could -- and I'll say easily, but you know--

Dave: Potentially better than me, right?

Chris: -- through 30 cents and 8 gallons of water, it could replace that alt="" with a pretty nice description of what's going on in there. You know?

There's a cost to these things. But would it be better with an AI description in there? Probably. Now even that has all kinds of implications. It could get it way wrong. It could get the vibes way wrong and the vibes do kind of matter in there because you could be telling a joke with the image you put in your blog post, and that joke could absolutely not come across. There could be data buried in that image in your blog post and it could get the data way wrong. There are problems with this. But probably on the whole, it's a little bit of an improvement if that were to happen.

Dave: Yeah. Yeah. I mean you think about... We were talking about it in the Discord yesterday even, just like what should empty alt, and somebody was saying anecdotally, I worked with somebody who used a screen reader. And they were like, "Please just describe the image. If you put it on the page, just describe it. What is it?"

It's like, "Oh, it's there for vibes." It's like, "Well, then tell me the vibes. Give me the vibe."

Chris: I saw that. That was an interesting anecdote that even something that probably you or I would almost certainly claim as decorative and, thus, intentionally not put an alt attribute on because it's just some curly border or some crap on a box that just has nothing to do with the content, that we're wrong.

Dave: Yeah.

Chris: That particular person anyway, and it's hard to paint everybody. Just because one person who prefers it one way doesn't speak for the entire community of people who have those needs. But still, this person would prefer it to be explained.

Dave: Yeah. Yeah, it's very interesting. And I think about, you know, I post pictures of my little robot Gundams, and I try to write alt text, but I struggle because I'm like, "How deep do you want me to go?" because I could write a book on my little toy. [Laughter] I've got my favorite son, you know. But is that useful or do you just need to know it's a yellow robot that's kind of fat? Or do you need to know it has red piping on the arms, elbows, and ankles? Do you need to know all of that, or the head is proportionately smaller than the body?

Chris: Oh, it's so subjective. You'll never get an answer to that. Some people probably want more. Some people probably want less.

But I would think the most important thing is if it's trying to evoke a vibe, then explain the vibe with words.

Dave: Yeah.

Chris: Or emotional.


Chris: I do have a question here sitting here from our number one question asker Simi de Clercq, that says, "What does accessibility actually mean?"

Dave: Ooh...

Chris: "I feel like there's a lot of not accessible shaming doing the rounds. But without enough of a clear explanation of what that actually means, what's wrong, a nudge on how to fix it, what are good resources to learn that?"

I just like that opening thing. What does it actually mean? There are... Certainly, it is tempting sometimes to be like, "Oh, it's screen readers."

Dave: Mm-hmm.

Chris: It's the thing where if you're blind then obviously you can't see the image so you need the alt text and stuff. It's very easy to just be like, "That's the thing that we mean when we say accessibility," except for that that's never been true, really. It's really a much broader brush than that and it has to do with anybody with a disability of any kind trying to use the website.

I thought what stuck with me just year after year after year after year was this post by Anne Gibson. She originally wrote it on

Dave: Ooh...

Chris: A quick aside, The Pastry Box added a lot of... asked a lot of people to write for a lot of years, and then they just turned off the website.

Dave: Oh, man.

Chris: I find that so uncool. Can't somebody? You could have asked the community. I would have done it. Just give me all this crap. I'll put it up on... I'll do a little 11ty build on it, and I'll throw it up on Netlify so at least it's not gone forever. Like, what the hell happened there?!

Anyway, you can find it on--

Dave: Yeah. I forget even who did that, like who was behind that. Yeah, that's interesting.

Chris: I think they're decent people. Something had gone wrong in their life or they made some bad decisions because taking that crap off the Internet.

You know what? None of my stuff is gone because I was cross-posting it to my own site, and I always thought, you know, I had in my mind, "I'm doing this because this might happen." But I always felt a little bad about it because I'm like, "Of all the projects in the world that's never going to just turn off, it's this one." It's not just one person's writing. It's like you've asked hundreds of people to write for you. You have an obligation to keep this thing online.

Dave: Yeah. Yeah.

Chris: So, you know, I didn't have to do anything because I cross-posted the whole time. But I feel bad for Anne Gibson, for example, who wrote in 2014, so 10 years ago now, a wonderful post that, again, this is the one that stuck with me year after year after year about an alphabet of accessibility. She did an A through Z post - classic blogging fodder, right? Really fun.

Dave: Perfect. Yeah.

Chris: Then posted it. You can find it on the way back machine. It was "A is this, B is this, C is this." Now, if you find it, it's somebody who just shamelessly stole it.

Dave: Mm-hmm.

Chris: They're like, "Credit to her." I'm like, um... I don't know that that's okay, though.

Dave: Did you, though? Yeah.

Chris: Yeah.

Dave: Yeah.

Chris: But it's not even supposed to be like, "A is for acrobat. B is for bellhop - or whatever." It's just like a list of things. It's like person A is blind. Person B fell down a hill and fractured multiple fingers. C has blood cancer and is on chemo and is finding it hard to remember things. D is color blind.

And so, I'm doing the same thing. I guess I'm just stealing from Anne as well, so I'll just stop there.

You can support Anne by buying... She made these things into designed cards. They're like big, beefy playing cards.

Dave: Yeah.

Chris: That you can buy to facilitate discussions at your company. So, those are really cool.

Simi is asking about what is accessibility. It's that! It's not just the screen reader. Yes, of course, it's blind people. But it's also people who are in an emergency or something. Eric Meyer beat that drum for a while. I always liked that one. Kind of thing like, "I'm at the hospital. I need to know some information right now." Have you dealt with that type of accessibility?

And the, "I only have one arm right now." I broke both of my arms a couple of years ago, and it kind of limited my mobility in a way. Can I still use websites in that kind of situation? Is that a form of accessibility? Yes, of course, it is.

Dave: Yeah.

Chris: Then there are ones that people can see but are totally color blind. That's an issue. There are all kinds of different ones. Some are more obvious than others but it might be worth looking at Anne's cards to see the A to Z of different things.

Then what is accessibility? It's making the Web work for that whole list of people.


Dave: No, that's a really great way to put it. I think, for me, I see accessibility as if there's a Venn diagram. There's UX, which is user experience, like people having a good time on a website. And then, inside that circle there's a smaller circle, and it's accessibility. It's making... It's people who believe it should work, a website should work, for literally everyone. Hopefully, that circle is huge and everyone believes that. But it's not. And the number of people who do that is very small.

It's the subset of UX that's making it work truly for everybody. And I think it's hard. There's sort of... And then you get into the more academic or official WCAG, which is the Web Content Accessibility Guidelines, which if you're in Europe or Canada and maybe eventually the United States, you need to conform to that guideline. Then there's a bunch of rules, 57 or so different rules you have to kind of meet.

But they're all broken up into four areas. Perceivable: Can people read the content or see the content or hear the content? Operable: Can people operate the website with a keyboard, a switch, like a little switch that's kind of like a tab, or an eye-tracking device or a voice command device? And is it understandable?

This one is sort of... Is it easy to understand what's going on? Do you have confusing software metaphors? If I click a button and it changes something out of sight, does that work? Is it understandable and robust? Is the underlying technology clean? Are you using good HTML, basically? That's sort of the last part.

That's it. They call it POUR. Are you abiding in that spirit of making it perceivable, operable, understandable, and robust? There are guidelines that go along with that. There's success criteria, pass/fail.

Chris: Yeah.

Dave: But that's a lot to take on if you're just dipping your toe into accessibility.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you buy Miro. Thanks for the support, Miro.

Miro is really a tool for teams. You can think of it as an online visual workspace; really great for visual people like me. Or you can think of it as like an infinite canvas tool.

You make Miro boards, and they can be anything. In fact, you go to do it, and there's all kinds of templates in there for what a board could be. You're not even limited by these templates, but they really get your mind going on the possibilities of what it can be.

For example, project management is one of those things. For example, I can make a Miro board like a Kanban board kind of thing where I have tasks and the tasks are cards. And the cards can be from any source.

Dave and I were just in there today doing some episode planning, so our columns for our Kanban might be, for example, ideas or in progress, invited, recorded, finished. And we can be dragging the cards in between to keep us all on the same page.

Dave is in Austin. I'm in Bend. We're not together. But through a Miro board, we can do this in real time. In fact, we were in a meeting, and we were doing all of this together.

We were like, "Okay. What's a great episode idea for a show?" We're dragging on the avatar of the guest. Then we're dragging on (in this beautiful Miro board) ideas for what we want to talk to them about. So, we're just brainstorming together in this kind of permanent way that's a permanent part of this Miro board.

But I can do it alone, and Dave can see it later. In fact, I can record a talk track to go with it and talk him through what I was thinking about - a tremendous feature of Miro.

And then we're on the same page. We've got a plan. We can rubber stamp the thing and say, "That's what Season 23 of ShopTalk Show is going to be all about. These are the guests." Thumbs up, thumbs down, all that kind of planning. So good.

Find simplicity in your most complex projects with Miro. Your first three Miro boards are totally free - very generous of them - when you sign up today at Again, that's three free boards at

[Banjo music stops]


Chris: A couple of other things. One of them was bitched about on Mastodon the other day, and you were surprised at this as well. I used the angle bracket, the native dialog element in HTML.

It was a cool moment, too, because I've been writing for Frontend Masters Boost, just my little... kind of in the same spirit of CSS-Tricks. I like writing about Web tech stuff, so why don't I do it for them? They're a neat company and were big supporters of CSS-Tricks, and I like their vibe and all that stuff.

On the homepage of their site, they have a little quiz you can take. It's not a quiz to test you on Web tech. They have a lot of content on their site. So, if you're a person, who are you? Are you a manager or developer? What are your interests? They basically ask three demographic-style questions, but not like male-female, but just like stuff about what you do industry-wide.

At one point, when Boost was coming up, they were like, "We should put that over there, too." I'm like, "Well, that sounds like a Web component, doesn't it?" You know? Like, "Why don't you make it into a Web component? Then you can use it everywhere."

I made a CodePen quick that showed them how I might approach it, and I was really hot on Light DOM at the time, so I made it a Light DOM, so it could be easily styled and all that.

They kind of bit on it, and they made it a Web component. So, I was like, "Ooh, I'll show you how you can do this Boost then." It's a little... I think it could squish down into a sidebar size - maybe. But here. You know what? We'll just have it open up in a modal instead.

So, I took their Web component, which was ready to use. And I just put it inside of angle bracket dialog and then had a button open that dialog, and it just works perfectly.

Dave: Yeah.

Chris: It's such a satisfying moment of Web technology just coming together to work super well. So, that's literally what you have if you're looking at a post on Boost. There's some little button that says, "Take a quiz," in the sidebar. If you pop that open, that's just all pure native Web tech making that happen.

Dave: Oh, wow.

Chris: It doesn't come with--

Dave: ...web component ... interactive dialog?

Chris: Yeah.

Dave: I put one inside a details the other day. Whoa! Weird. What? What?

Chris: Yeah.

Dave: Yeah.

Chris: Juicy.

Dave: Just doing it.

Chris: Really satisfying. So, there's some more to say there. At one time, when you click that, take the quiz thing and it opens up, I wasn't seeing it on iOS. I'm like, "Oh, wow. Is there some iOS bug or something with this?" But it turns out it was just because I was scrolled down.

Dave: Mm-hmm.

Chris: I thought, "Oh, why is it--?" And then if you hand-finger-scrolled all the way back to the top of the page, you'd see it up there.

Dave: Mm-hmm.

Chris: I was like, "That's a weird choice. Why wouldn't--?" And if you're playing around on other browsers, you can see that as soon as you open up a dialog, you kind of get... you've kind of got to scroll to the top. I was like, "Oh, they did that, but iOS doesn't scroll you up to the top." It turns out that's not it. That's not what was happening here.

What was happening here -- and we covered this with Brad as well -- the dialog, it doesn't have a close button. You just don't get one. If you want a close button, you've got to bring your own.

Dave: Mm-hmm.

Chris: Where does it go? Where would you put a close button in a dialog like that? Well, I think a lot of people would put it in the upper right.

Dave: Yeah.

Chris: A lot of stuff for that. So, my mind immediately goes, "Oh, dialog, position relative, close button, position absolute. Top zero. Right zero." A little offset, or something like that.

Dave: Mm-hmm.

Chris: Well, by making that dialog position relative, you have screwed the pooch.

Dave: Whoops. [Laughter] Yeah. Yeah, yeah. Now it doesn't sit in the middle of the page. It just goes where it was. Right?

Chris: Yeah.

Dave: Yeah.

Chris: It does still show up in the middle because of the margin auto stuff.

Dave: Okay. Yeah.

Chris: There's enough going on that it still kind of shows up where you hope it shows up, but not when you're scrolled down.

Dave: Oh, yeah, yeah.

Chris: Position fixed, when you're scrolled down, it will just be right in the middle of the page nicely. Now there may be reasons to make it display relative and stuff. If you had a dialog that, for some reason, was taller than the height of the entire page, which I hope you don't, but if you're in that position someday, position fixed would be a bug then; it would be a problem because you wouldn't be able to quite scroll how you wanted to unless you had other interventions like setting the max height of the thing to 100 viewport units high and making it scroll and stuff like that. There are tradeoffs here, but I get what they did.

But my immediate intention of position relative (because I needed a formatting context for absolute positioning) boy, don't do that. Use some kind of inner div or something for that, for that context. In fact, you know what? You don't even need the inner div because position fixed is a positioning context. So, you can absolutely position within there without doing anything at all.

Dave: Oh, yeah. Okay. Yeah.

Chris: Now you've got a close button. You call dot close on the dialog. All is well.

I do think it would be nice to have an option to be able to click the backdrop to close it. I think that would be an improvement to....

Dave: Yeah. I think it's--

Chris: Probably intentional.

Dave: It's a couple of lines of JavaScript to make that work. But then you get into event listeners on the body and then listening and stuff like that.

Chris: And it could be unexpected, like if there's a form in there. Do you really want that?


Dave: Yeah, well, so, there's light dismiss coming from inside popover, which is the idea of clicking the body and it goes away.

Chris: Yeah.

Dave: That's being called light dismiss or escape closes it. That's also... that will work in a dialog.

Chris: You get escape for free.

Dave: Yeah.

Chris: Yeah.

Dave: So, that's pretty powerful.

Chris: It is! That's very cool.

Dave: Yeah! You're just like, "Okay, I didn't have to write a key handler." That's plus-plus. I love it.

Chris: Mm-hmm.

Dave: But I think light dismiss is maybe going to make its way as a param or something.

Chris: Is it the popup or the popover API - or whatever it is? That one seems--

Dave: Popover API, yeah.

Chris: That's the one that's a little bit more menu-like.

Dave: Mm-hmm.

Chris: And you can... I'm sure this is true on Windows and Mac and everything. If you go up to the top of your computer right now and single-click a menu and then single-click outside of that menu, it will close.

Dave: Yeah. Yeah, and so that's the behavior that's coming to popover, and it will hopefully... Yeah, I think they're going to maybe port it over to dialog eventually. But I don't know when or if.

Chris: Mm-hmm.

Dave: Right now, you have to kind of do the click background dismiss.

Chris: We have a component at work called the click outside detector--

Dave: Yeah.

Chris: --that we use for this, and it unfortunately works largely good but has been source of many a bug over the years.

Dave: Yeah.

Chris: So, you've got to be careful with that.

Dave: Yeah.

Chris: We have an open one right now, I think. Yeah. Ugh.

Dave: Really?

Chris: Yeah.

Dave: From click outside detector?

Chris: Yeah, but it's mobile specific. It's like you scroll too fast and the scroll sometimes triggers it or something.

Dave: Ah...

Chris: But our implementation is fairly complex. I'm sure it's hundreds of lines of code, so there's some problem in there.

Just in the Discord the other day, it was noted that there's another way to close a dialog, though, which is a form submission in which you explicitly tell it to close the dialog.

Dave: Yeah, you add form - what is it - method equals, right? Sorry. I'm blank... I messed it up.

Chris: Well, it's action for a form.

Dave: Action.

Chris: Well, isn't action tells it what URL to go to, so you kind of still need action. Is it in action?


Dave: Uh... Let me look it up. I'm going to, the new shortcut to go to any--

Chris: What?!

Dave: Slash whatever you want to put in there, and it'll find the first, most relevant article.

Chris: Wow! And I notice there's a little hop to Bing. That's weird.

Dave: Yeah. Okay, so here it is. So, it's button, a form method, so you wrap it in a form. You have dialog ID favorite dialog. Form is the first child. And then in there you have a button called value cancel, button value. But then you have form method equals dialog. Right?

Chris: Form method, so it's kind of a new--

Dave: Form method.

Chris: --a new attribute.

Dave: Right. Then this is your cancel button. Any other button will close the dialog or will submit the form in a form. But a form method dialog will close the dialog.

Chris: Nice.

Dave: That seems poorly named, now that I'm saying that out loud, but that is what it is. But what that will do is it'll save the state of the form, but it'll close the form.

Chris: No?! It saves the state of the form?

Dave: Yeah. Yeah, I think it's so it doesn't submit the form but it holds onto it.

Chris: Secret ... storage stuff? Then you open it again and it repopulates the form?

Dave: Yeah, the form is saved but not submitted, and the dialog gets closed.

Chris: Wow!

Dave: It's sort of like if somebody wants to back out and you don't want to wipe out or tear down all their work, that would be a good use case for it.

Chris: That's amazing! But I guess... hmm... That weirds me out. It's like if you close the dialog, the form isn't removed from the DOM. I would expect it to still have the content in it even though the dialog is closed.

Dave: Mm-hmm.

Chris: It better anyway. I was looking at David Darnes's. He wrote a nice little Web component.


Dave: David Darnes!

Chris: Yeah. I forget what it's called now. Sorry, listeners. You should be able to find it pretty easily, though. We'll put it in the show notes.

You just wrap it around a form and then it just automatically, every single form element gets saved to local storage as you're messing with it.

Dave: Oh, yeah, storage form, storage-form.

Chris: I was like, "This is great. WordPress should use this for the comment form." Dude, duh.

I thought of it because every time I'm on GitHub, I'm halfway through writing up a PR description or whatever, and I'll accidentally click away or something dumb.

Dave: Yeah or you hit delete. Somehow your cursor is at the beginning and you hit delete. Then you just [pew] goodbye. Yeah.

Chris: Goodbye. But I'm trying to tell you the opposite, though. If you click away on GitHub and then you come back and open that PR again, it saves it. What you were writing is in there. You're like, "Ooh, good job."

Dave: Nah, that's cool. It's killer. Killer feature.

Chris: Killer.

Dave: Yeah.

Chris: All right. I've got to keep going on this Web component stuff because it's so interesting to me.

Dave: Yeah. Keep going.


Chris: Okay. Yeah, you can close the form multiple ways, dialog, whatever. It's now... I'm going to call it on production even though it's our alpha product, so you can't... CodePen users won't see it right now, but we had a use case where we were absolutely forced into using a Shadow DOM Web component this week.

Dave: Ooh... Forced.

Chris: I think it's forced.

Dave: Okay.

Chris: Here's the deal. We use Next.js for stuff at CodePen recently. I hate to be a React apologist. I'm not, in a way. But it's a very nice technology for what we're doing with it. And I think a lot of people would agree. It's long sessions. It's just helpful. It just feels like a good choice, actually, and not in the way that people are like, "I'm going to use it for my blog," or whatever. And you're like, hmm... But whatever. I hate to have to caveat that. I feel like it's--

Dave: But, Chris, you can like React, man. You can like React. Just enjoy it.

Chris: I'm so-so on React, but Next is nice.

Dave: Okay.

Chris: So, okay. The nature of any of these frameworks is that they can re-render the page kind of whenever. You know? It's like you don't call a render function when you're working in React. It's just like, "Oh, some data changed or state changed. I'm just going to re-render whenever."

Sometimes it's a little unclear when that actually even happens, especially as your app gets super complicated and there's lots of state and data that is changing. Like, what's actually re-rendering at any given moment?

You try to watch it. There are little tools to watch it. But it's a little unclear.

You know what? It can also re-render things you don't even see like the head of your document. You don't see the head. How often is your head re-rendering, Dave? Who knows?

Dave: Who knows?

Chris: I have no idea, but it does happen sometimes. There's a head component that even something like Next.js gives to you.

Dave: Yeah. Yeah.

Chris: If the head is called whenever... I think the NFL originally created it. Maybe they called it helmet or something.

Dave: Helmet, yeah.

Chris: I thought it was cool, yeah. But it's like you can call it whenever, anywhere, and it will put that stuff in the head for you, which I thought was kind of nice. You're like, "Oh, I changed something on the page, and I actually need the title to change," so you can put the title attribute in there.

Dave: Like a progress bar title kind of thing. Yeah, yeah.

Chris: Yeah, sure, or I need to add a metatag in this particular environment - or whatever. We use it a little bit. I don't think that's the case here. But the point is that the head is one of the interact developments on a complex Web app, for sure.


Chris: We also use (very crucially to CodePen) this app called CodeMirror. CodeMirror is the code editor itself.

Dave: Mm-hmm. Mm-hmm. Yeah.

Chris: Pretty fancy stuff. It has lots of styling and stuff and it's all complicated because it's like, "What syntax highlighting are you in right now? Oh, we need little tool tips inside of there to show certain types of errors and stuff." There's all kinds of extensions and stuff.

The way that it handles styling, particularly in CodeMirror 6, which is the newest version that we're using, is it does a lot of putting a style attribute in the head or a style tag in the head. It'll just dump one in there because it's a JavaScript library and a lot of its styling is done through JavaScript.

So, when it does that, you can see it. You can be using CodeMirror 6 and just use the Web inspector and go, "Oh, I see a style attribute sitting right there in the head."

Then Next will do something, something, something, and wipe it out. And you're like... and then CodeMirror is bonkers broken. Next tries a little bit to help with stuff in the head because sometimes you just... you don't know. Weird companies use Google Tag Manager, for example, which opens a portal to hell on your site. Who knows what JavaScript is getting added to your site, and that JavaScript is calling other JavaScript. It's injecting crap into your head. Whatever.

Next.js is too big of a framework to just be like, "Oh, you can't do that."

Dave: Mm-hmm. Yeah.

Chris: Of course, they need to support this. So, they try to maintain what's being dynamically being messed with on your site, but for some reason, it's very hard to necessarily know. And I think we did some digging, and we kind of got to the bottom of it. But there was no clear solution. CodeMirror style elements just get wiped out. Okay, the stage is set now, right?

Dave: Right. Right.


Chris: One of the things we could do is render CodeMirror in a ShadowRoot. If you do that, CodeMirror is smart enough (thankfully) to mound the styles that it needs to that ShadowRoot, like it has no choice. It can't reach outside of the ShadowRoot. That's the whole point of a ShadowRoot.

Dave: Right. Yeah.

Chris: So, it mounts the styles inside of there. Thus, Next can't mess with it. It can't. It's not ripping out those styles. So, it totally solves this problem. Nice, right?

Dave: Yeah.

Chris: Now we have a Shadow DOM Web component that mounts it inside of it. Now, the story unfortunately doesn't end there because you can't... just picking up a part of your application and chucking it into a Shadow DOM... how is that going to go? You know?

Dave: Yeah. Yeah.

Chris: I'd say mostly it went fine. It's just that, for example, sometimes we need to render some componentry that we already have inside CodeMirror. We have this very special file diagnostic component that tells you about errors and stuff. "On line 7 of your document, there's some problem."

Now, where is it going to get the styles from that? Hmm... You know? I've been banging this drum on this show and blog posts forever. It's too flipping hard to style through the Shadow DOM.

Dave: Yeah.

Chris: Where do you get the styles from this component? Where? It's like if we had little, individually, vanilla CSS styles for these components, well, then we could... I could do a little fetch for them as a constructible style sheet, and then mount it to it - or something. Or maybe during the build process; we can dump the CSS into a style tag.

But I'm like, actually, our styling is a little complicated. We use Sass. We use CSS Modules to scope the styles. We have a whole system for that. It's not very easy for me to get my hands on that tiny little piece of CSS that is just for this one component.

Dave: Yeah.

Chris: It's not impossible but it's really not easy to do. Now, of course, if I had what I was asking for, which is just some kind of CSS selector that will allow me to push those styles to the Shadow DOM, hey, no problem. That doesn't exist, unfortunately.

Dave: Right.


Chris: What we ended up doing -- and this was Stephen's solution, and I'm glad he kind of found it -- is slotting, essentially, which you're I'm sure very familiar with. But if you need to render something inside the Shadow DOM, one of your options is put that element actually kind of outside the Shadow DOM and say, "I'm intending to pick this up and move it inside the Shadow DOM." When you do that, the styles from the Light DOM that applied to it come along for the ride.

Dave: Yeah.

Chris: It's a little... I didn't... I don't know if I really had that in my mind.

Dave: It's weird. I wish there was a banner, like, "If you wrote it, you can style it. But if the Shadow DOM writes it, you can't do nothing."

Chris: Yeah.

Dave: But if you wrote it, you can style it - for the most part.

Chris: It's weird to look at an element that's sitting right there in the Shadow DOM being styled by Light DOM.

Dave: Yeah. Yeah, yeah.

Chris: But that's just kind of how slots work. Yeah, you said it better than I did. Anyway, that's kind of a solution. If you're slotting, you can style from outside. It's fine.

Dave: Yeah, and there are some gross things you can do, like you can yoink that Light DOM. You could send the component and put a style tag as a slot, and then you could clone that Light DOM chunk and put it into your Shadow DOM. Then that becomes shadow styles sort of thing.

Chris: Yeah.

Dave: But it's sort of like, how gross do you want to be? One cool thing about slots, too, is you get this slot changed event. So, if the slot ever changes, like somebody updates styles in preferences or something like that, batta-bing batta-boom, you can update the code thing as well.

Chris: That's nice.

Dave: Yeah, so that's kind of a neat reactiveness inside.

Chris: While I was kind of advocating for Light DOM usage... you know I think a lot of people are. Anybody that's really into that HTML Web components kind of banner is pretty Light DOM heavy. You are giving up slots, and slots are a big deal. Slots really up the ante of what's going on in Web components in a big way. It sucks that you can't use them if you just go all in on Light DOM.


Dave: So, I made FitVids, and it was all HTML Web component. You know that was kind of part of the whole kickoff on HTML's Web components resurgence here. But I think I either PR'd it or merged it. I think I just PR'd it and didn't merge yet. But I rewrote it to use Shadow DOM because that's the whole padded box thing. You kind of actually want that to be Shadow DOM.

Chris: Hmm...

Dave: Inline is a little clunky, so Shadow DOM is kind of a really good use case. I'm just going to apply this really specific set of styles to this thing as an enhancement and then it's going to be good. You know?

Chris: Yeah.

Dave: So, you probably won't have to futz with it.

Chris: Please don't reach in and change those. That's a whole part of this conversation that I find interesting is, as much as I might bang this drum saying, "Give me CSS control over these Web components," it breaks this kind of preexisting contract with component authors that knew for a long time that users couldn't do that. And if all of a sudden they wake up tomorrow and now the users can do that, it's kind of this broken promise of, like, "No, no, I was authoring components very expressly so that that couldn't be done."

Dave: Right. Right.

Chris: There needs to be a way to not break that promise somehow.

Dave: Well, and to be honest, there's been some developments. Brian Kardell made this library. It was based off of a Nolan Lawson post. And he made a cut of a library, but then, through some feedback from me and Miriam, came out with this thing called half-light, which is sort of doing what you want it to do, and it's this--

Chris: I saw that. You write a media query and that's just a way of signaling to this library that's like, "Hey, could you please pick up this group of styles and go put it in the Shadow DOM for these other things?" Very clever.

Dave: Yeah, so his is at media screen, so everything gets it. Right? But then ,--cross-root, and that's not final. That's not what it would be in HTML land - or something.

Chris: Yeah.

Dave: But just this idea of, like, "Hey, this bucket of styles that you're about to encounter is for cross-root ARIA.

Chris: Yeah.

Dave: Sorry. Not cross-root ARIA but cross-root Shadow DOM.

Chris: We almost used it. I was trying to advocate to use it because I was like, "Oh, shoutout. This is going to be useful right away." You look through the code. It's very cleverly written but it looks for every single ... element, every single style element, and is constantly watching them with a mutation observer.

Dave: Yeah.

Chris: An application of sufficient size, you can't. That's heavy sauce, man.

Dave: That's some memory, yeah. Yeah, yeah.

Chris: Yeah.


Dave: So, I think what's cool about it is there is a theoretical possibility. It's like 66 lines of code - or something like that. And so, I think there's just this idea that we are going to be able to pierce the Shadow DOM.

I think that's going to change, like you're saying, Web component authors' perspective. I think if we have something like this, I mean why would you ever use part? Why would you ever use some of these--?

Chris: Oh, my God. Part can just... oh... I just want to slap it. We don't need that much CSS put into this, for example. But one of the things that we lost was custom scrollbar styles.

Dave: Oh, yeah. Yeah.

Chris: So, we had to put it inside. But we were like, "Oh, no problem. I'll just select the root of the Web component inside with a part, and then I'll apply the custom scrollbar styles to the part."

The problem is we're still in weirdo scrollbar land, Dave. You have to use dash or ::-webkit scrollbar for Safari, for example.

Dave: Right.

Chris: Chrome is now right in the middle. I don't know if you knew this, but this is like a PSA almost. If you use scrollbar color and scrollbar width, those are the ones that Firefox supported forever. Those are the actual standardized ones. Chrome is supporting those now.

Dave: Ooh... interesting. Yeah.

Chris: Very interesting. If you use one, either one, it wipes out the --webkit ones.

Dave: Ooh...

Chris: They are overridden, which is probably the smart call there. The problem is the old ones had more power. So, for example, let's say you had horizontal tabs that are too wide of the container, so you want them to scroll horizontally.

Dave: Mm-hmm.

Chris: I would often put -- now slap my wrist if you need to here, but -- a one-pixel scrollbar on those because you're like, "I don't have--" the whole tab is 13 pixels tall. I don't need another 13 pixels for the scrollbar. It looks like crap.

Dave: Right. Right.

Chris: And I'm like, it works with swiping. It works with your scroll wheel. I don't know that you need to crab it with the mouse. It was just kind of a visual indicator that there's more to the side.

Dave: Mm-hmm. Mm-hmm.

Chris: So, I'd make a really thin one. Well, you can't anymore if you use both styles. So, there are solutions using at supports and messing all around with this to kind of get it to go. But my recommendation is probably just deal with it. Just use the standardized styles.

But anyway, part, if you try to say, "Oh, I'll just put a part on that thing that scrolls and then I'll attach the scrollbar styles to the part," no you're not because part--

Dave: Hmm...

Chris: You need to select the part and then do a pseudo element on the part, and you can't do that.

Dave: Oh, you can't pseudo a pseudo, huh? Yeah?

Chris: No. Well, you can pseudo a pseudo in real life, but not here because part is... You know how you can't select a descendant from a part either?

Dave: Mm-hmm.

Chris: On purpose.

Dave: Right.

Chris: They said, "This is our thing. One level deep only," and I think a pseudo-element breaks that rule. But that's why I hate part. It's not CSS. It's so dumb. Ugh!

Dave: Yeah. Hmm...

Chris: [Laughter]


Dave: I think that needs to be redesigned or taken out. It seemed like a patch fix.

Chris: Yes. That's right.

Dave: What's a cheap, easy solution for a fix? That was... Rather than ... cross-root styles, what's the cheap fix? Okay, cool. Let's do this.

Chris: [Blows a raspberry]

Dave: I think I've seen a few more, like cross-root ARIA is going to happen, and I think that's good. We do need something. But then there are other specs that are very similar for cross--

Chris: It doesn't even help get custom properties in - or something. I'm like, if you had to part the root so that you could then pass in all your custom properties, oh, maybe. Guess what. You don't even need to.

Dave: Yeah. Those go through.

Chris: It works without part.

Dave: Those sail through. Yeah. [Laughter]

Chris: Right.

Dave: And that's what's confusing, too, is some stuff sails through and some doesn't. This is all covered, of course, in my Frontend Masters course "Introduction to Web Components."

Chris: Yeah.

Dave: Or head over to That's a website guidebook.

Chris: Yeah.

Dave: Check it out.

Chris: I just wrote a little plug for you. I was putting in a little componentry thing at the bottom of a Boost article. Right now, if anybody publishes anything on Boost that uses the tag "Web components," it puts a plug for your course at the top.

Dave: Ka-ching! Well, I will say, hey, I got a little insider knowledge. We've got a bit of a boost last month. I'm no - whatever - React course of Primagen algorithms course or nothing like that.

Chris: Right.

Dave: But Web components saw a boost.

Chris: Did you?

Dave: I've been seeing a boost. It's not buy a Ferrari money or nothing like that. No Lambo. No PHP Lambo.

Chris: Yeah.

Dave: But it's getting... It had a boost.

Chris: There's a lot to learn, I'll say. This was very interesting to me who often speaks of it theoretically or builds little baby ones. When I had to go prod on this thing and have it actually work in a production environment, holy crap was there a lot of little stuff to know about, little gotchas all over the place.

I found font family didn't come through nicely in Safari. We had to reach in and it didn't cross the boundary. I'm like, "Oh, that's nice."

Dave: Custom fonts don't. [Laughter]

Chris: Yeah.

Dave: That's frustrating. That's so stupid.

Chris: Yeah, that's what it was. That's what it was. So, we had to dig that. I'm like, "Why is that different? That's ridiculous."

Dave: Yeah.

Chris: Also, you know how you have to... custom elements are display inline by default?

Dave: Yeah.

Chris: That's pretty obvious, right? Then you've got to go display block it. It could be a little gotcha for people.

You know what else are display inline by default? Slots.

Dave: Hmm... Yeah.

Chris: That got us, too. You've got to block your slot, too, because we had this thing that needed to measure the height of it, and the height was coming back way wrong. And it took us a little bit, Stephen a little bit, to figure out we needed--

Dave: [Laughter] "We."

Chris: That's, Stephen.

Dave: The royal we.

Chris: "We," I mean--

Dave: Stephen.

Chris: I was around and Stephen figured it out.

Dave: Iโ€™m a very good listener on Slack. Please no calls.

Chris: Yeah. [Laughter]

Dave: But on Slack, I will listen. Yes.

Chris: I bet there were ten more, just little, dumb things that... Not dumb, but it's a learning curve, right? I'm sure you do this your tenth time, you're like, "Oh, it's fine. It got it." You know?


Dave: Oh, I don't. For me, even still, especially when you're not using it full-time, there's always a bit of a bite when you go back to it. You asked me today, "Hey, Dave, how do you pass JSON, like a string of items into a lit component?" I don't know. I think it's a colon. [Laughter] I think there's a colon involved. Then the attribute - or whatever - to make it a property or something. But I don't know for sure.

It's that thing. It's like you work in Vue a whole bunch. You go to Web components. Oh, gosh. It's so similar, but then there are little bites--

Chris: Yeah.

Dave: --that you have to kind of rewrap your brain around.

Chris: Yeah. We had to make a component, and we had to... There's a lot of - a lot of state it had to manage.

Dave: Mm-hmm.

Chris: That React was managing. But fortunately, that was not so bad. We got through that pretty quickly. But then you forget little things, too, like React is smart enough. And we're on 17, not 18. I think 18 is better.

I don't know what's better, exactly, but even 17 is smart enough to know, "Oh, it's got a dash in the name, so this is a Web component." So then, even though the rest of your entire code base uses class name instead of class, it can't. You have to go back to using class on that element.

Dave: Ew... ew...

Chris: That's a little gotcha-rino in React 17.

Dave: Yeah.

Chris: Not the world's biggest deal. Those are easy to get past. The stuff of, like, how are we going to get the styles to come through was a much harder problem.

Dave: Well, I'm glad it worked. I'm glad it... It sounds like it solved a problem.

Chris: Yeah. Having a protective ShadowRoot is, and I think it will. It did, and I think it might be smarter, overall, to have something that's that complex be kind of isolated from the rest of the page. It might just solve future problems that we don't even know about yet.

Dave: Yeah. I mean there is this sort of like you're putting a little fence. You're drawing a fence around the component that you have to be very explicit about going through, and that can be beneficial.

Chris: Yeah. It can be, indeed - you know.

Dave: Well--

Chris: Well, thanks for listening to my whole thing there.


Chris: A couple of minor things to slip in at the end. jQuery 4.0 came out. I think that's just cool to say.

Dave: Yeah!

Chris: Good job, jQuery. Looking up through their thing.

Dave: Oh, I'm updating all my sites. No, I'm just kidding. [Laughter]

Chris: I would.

Dave: You don't update jQuery sites. Come on! No one updates jQuery sites.

Chris: CSS-Tricks used it, you know, but they took me off the repo for it. Wah-wah.

Dave: Ah...

Chris: Which killed me. I needed to look back on something. I needed to go grab some old code from CSS-Tricks, and I have a copy of it. It was my site. I assume that's not a problem. But what I don't have is every change that ever happened. I just have a zip file--

Dave: Yeah.

Chris: --of basically as I left it. But you know what was in the zip file? The .git directory.

Dave: Ooh... okay.

Chris: Which that does have all the changes on it forever. So, I was like, "Oh, well, thanks." I mean I solved my own problem there, but that's a nice thing to grab. If you're backing up a site, back up the .git folder too. Why not?

Dave: Yeah.

Chris: I was able to get the old code in there. What was I going to say? Yeah, that site used jQuery. I probably... you know it's something like five, six kilobytes smaller just for that. If everybody upgraded just that, that makes an overall difference on a site. That's not nothing.

Dave: We reduce the carbon footprint of WordPress considerably.

Chris: Yeah. And it's all ESM now, so if you were so inclined or you just like that import world, you can import your little dollar sign from jQuery. That might have worked before, but I think it's officially done-zo now.

There are just little things. I was looking down through the list of, like, what would it take for a jQuery comeback. You forget just how many really nice DOM manipulation APIs were in there. To this day, I'm like, "Oh, I need to add some... I need to insert some HTML into another element." You're like, "Oh, what is it, again? Insert a JSON HTML? Then what's the first parameter? It's like before end or something."

I like that API. But I've still got to look it up.

Dave: Yeah. Yeah, yeah.

Chris: You know? Whereas it's like jQuery had after.

Dave: Insert a JSON HTML - or whatever. Yeah.


Chris: Yeah. Things are just named better in jQuery.

Dave: My favorite is when you do $LI get all the LI's, right?

Chris: Yeah.

Dave: Dot add class foo, right?

Chris: Mm-hmm.

Dave: jQuery is like, "Heck yeah, I do it, dude." You do that in HTML, document query selector all LI class name plus equals foo - or whatever.

Chris: No, that doesn't work.

Dave: It's going to die because you have to do a for loop.

Chris: You gotta do the loop.

Dave: You have to do for each. Okay, now I'm doing the--

Chris: The implicit iteration, they called that in jQuery. It was an excellent feature.

Dave: It was excellent. But then what's even better, if you were, like, remove class foo, right?

Chris: Yeah.

Dave: jQuery goes through and says, "Cool. I'm doing that." And if it doesn't have the class, it just doesn't do anything. Normal JavaScript, if it doesn't have the class, it dies, so you have to do :has() attribute or :has() whatever.

Chris: Oh, right.

Dave: Class name contains - or whatever - or :has() attribute and then remove attribute.

Chris: I would think class list dot remove... class list ... remove dies if it's not there? Oh, that's horrible.

Dave: Classless maybe works, but if you're doing an attribute, so dollar dot adder.

Chris: Right. Right, right.

Dave: Foo=bar or remove adder or set.

Chris: Right. You've got to have a little protective JavaScript in there to make sure it doesn't.

Dave: JavaScript will die if the attribute doesn't exist.

Chris: [Blows a raspberry]

Dave: It's just like, "Man--"

Chris: Yeah.

Dave: jQuery was cool. [Laughter] There are times--


Chris: I tested this one because I saw it right at the top. Classlist.add is fine, but it is kind of a nested API, I guess.

Dave: Mm-hmm.

Chris: Whereas, you know what it was in jQuery? Add class and remove class, which is very clear.

Dave: Mm-hmm.

Chris: And it would just do little stuff. Now with classlist.add, I think they can be a space-separated string, but what if it's an array? jQuery is like, "Oh, it's an array? That's fine. I'll just put them both on there."

Dave: Love those. Yeah.

Chris: And it would take a function (for some reason). You know? If you want to have add class be a function and have it return what class because you needed it to do something--

Dave: Yeah.

Chris: It'd be like, "Fine. That's cool. I can deal with that."

Dave: [Laughter]

Chris: [Laughter] Its API was nice!

Dave: Yeah.

Chris: It was like, yes, we did get a lot of this in the native platform. And yes, you probably should just use the native platform. But you forget how just pleasant the jQuery API was. It was so chill.

Dave: Writing extensions was also really chill, too. You just dollar dot ... my thing, you know? Then you're off to the races to write a custom function that's chainable. It's chainable, Christopher.

Chris: You just got chaining for free.

Dave: Chaining for free. You didn't have to extend a prototype or do anything. You just got it. I mean I'm saying this as somebody with--

Chris: Maybe it's coming back.

Dave: I do have a signed copy of jQuery 1.4 up on my wall, so I mean, you know.

Chris: [Laughter]

Dave: I am a fan.

Chris: Kind of a fan.


Dave: You know where I think jQuery 4 dropped the ball, though? They didn't release with a 3D package, like a full motion graphic 3D reel, a sizzle reel to get me into the new sizzle. They didn't do any of that, Christopher. So, I'm really worried about the future of jQuery. I mean if they can't pump the marketing budget and be blazingly fast, I don't think it's worth doing.

Chris: Yeah. I agree. That's a real ball drop there, jQuery.

Dave: Hire me for your social media engagement. Yeah.

Chris: [Laughter]

Dave: All right. We should power down, huh? I think we're over time.

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 Mastodon at [email protected]. Then join us where the party is over in the D-d-d-d-discord. Currently, I think Dans are outnumbering Andrews, [laughter] so if you are Dan or Andrew, you've got to represent. But that's over at

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

Chris: Um... I don't know...