470: Slap a WAAPI, Explaining the Shadow DOM, LayoutNG, iFrames, the Web Animation API
Do you drive or fly in 2021? How do you explain the Shadow DOM? What's LayoutNG? How do iFrames and Accessibility work out? Should we be using CSS Prefers Reduced Motion? And what's up with the Web Animation API?
Guests
Chris Coyier and Dave Rupert
Time Jump Links
Transcript
[Banjo music]
MANTRA: Just Build Websites!
Dave Rupert: Welcome to a hard-stop edition of the ShopTalk Show. I'm Dave Rupert.
Chris Coyier: [Laughter]
Dave: With me is Chris Coyier. Hey, Chris. How are you doing today?
Chris: It's weird to be an adult.
Dave: No--
Chris: Live by the stupid calendar.
Dave: Oh, man. Today is the worst. For some reason, everyone decides -- we record these on Thursday, I guess, typically, just so we can get them edited by the excellent editor Chris Enns. A shoutout to Chris.
Everyone wants to meet on Thursday, Chris. I don't understand it.
Chris: Oh--
Dave: They all -- everyone on the planet decides--
Chris: Yeah.
Dave: --let's meet Thursday.
Chris: There's something about the not Friday-ness of Thursday that people like.
Dave: Yes, some good capture.
Chris: I'm taking Friday off. That's what I'm doing.
Dave: Ooh. Oh, heck yeah. Where are you headed?
Chris: Yeah.
Dave: You going up a mountain or something?
Chris: Yeah, we're going to go to -- a little further this time. We're going to go to the aquarium in [laughter] Monterey, which is a little plane ride for us.
Dave: Monterey. Oh, wow. Okay. Okay.
Chris: Which is a little south of San Francisco, a little fancy town.
Dave: Yeah.
Chris: They have this world-class aquarium and we're kind of like aquarium people, it turns out.
Dave: Hey! That's a good one.
Chris: So, be safe. We're both long past our vax, so let's do it.
Dave: Vax and go. Nice. Well, yeah. We have some summer travels.
Chris: Mm-hmm.
Dave: Family called for a summit. [laughter] You know?
Chris: Did they?
Dave: The family - yeah. Well, I had an aunt pass away this week. Not this week but this year. She was great, but then everyone just was like, you know, let's have a big meeting at my Uncle Tom's ranch in Colorado, which I think he's selling, so I think it's going to go away. And so, we're going up there. Then we're going to go visit my wife's family. And so, it's kind of like a "travel America" [laughter] road trip.
Chris: Yeah. You've done that before. That seems like the Rupert family classic trip, really.
Dave: I wish it wasn't, but yeah.
Chris: [Laughter]
Dave: We've logged some hours.
Chris: Yeah.
Dave: We are -- the plan is to fly, right? Fly into Denver and save about 34 hours driving.
Chris: Oh, yeah, dude. That's not optional in my book, really.
Dave: Yeah. It would be cool to road trip it, you know, in Phoenix....
Chris: There's the raw hours savings and then there's the difference of what those hours are like, too. When you fly, there is absolutely a bunch of stress involved with it, too. But there's all this time where all of you are just sitting in a row of chairs.
Dave: Mm-hmm.
Chris: And you're not having to just stare at the road. Nobody bother dad or mom - or whatever.
Dave: Mm-hmm.
Chris: That's different. You can go over to the little store over there that's probably the name of the newspaper in the city that you're in (for some reason) but all it sells is Coke and pencils.
Dave: It is.
[Laughter]
Dave: It's called The Statesman. Wow.
Chris: [Laughter]
Dave: Coke, pencils, baby books, and lots of coffee mugs and candles, I guess.
Chris: Yeah.
Dave: I don't know why they sell candles at an airport.
Chris: Neck pillows, magazines, and stuff. Remember when we were going to do a magazine podcast? That was fun.
Dave: Oh, we should. We should bring that up. I remember the old prepper segment.
Chris: Yeah.
Dave: [Laughter] Oh, boy! That turned out weird for 2020, didn't it?
[Laughter]
Chris: Yeah. Should have listened to our own fricken' advice is what we should have done.
Dave: I know. I need a knife that was also like a hammer. Ugh! I should have listened.
[Laughter]
Chris: I've got a People magazine in the mail from the neighbors - or whatever.
Dave: Okay. Okay.
Chris: But they were neighbors that I know don't live there anymore, so there's nobody to return it to. I was just like, "Ah, magazines. What a delight."
Dave: Free magazine, idiots.
Chris: Yeah.
Dave: So, yeah. That's great. Yeah, I don't even want to know. I don't know famous people. I'm really bad at famous people. [Laughter]
Chris: Yeah, you'd be surprised. Some of these BuzzFeed lists you end up scrolling through, you're like, "Don't know that person. Who is that? What? Are you famous?"
Dave: I don't know that person. I don't....
Chris: Especially when it comes to music, then I'm really clueless, which is embarrassing.
Dave: Ah, yeah. No, I'm the worst.
Chris: Send in your questions, please. Go to ShopTalkShow.com. Click that thing, and it's not just a question. It could be just some topic you think is interesting and worth covering and want to hear on the show. That would be great.
Dave: Mm-hmm.
Chris: Let's do some questions because we just have some because people have done that, which is great. Sam Warnick writes in. We've had other shows on this so, Sam, we won't dwell on it too long, but I do think you phrased the question well.
"Could you explain the Shadow DOM? I've tried to figure it out but it hasn't clicked yet. I've been able to figure out that it's like the DOM, but more shadowy." [Laughter]
Dave: Hmm. Hmm. Hmm.
Chris: "What's the deal? How does CSS interact with it? What problem is it trying to solve? Is it good or bad?"
Dave: Ooh, yeah. Um, so I have a talk on this about Web components. The way I think of the Shadow DOM is, it's an egg, right? [Laughter] I know metaphors are really labored, but everything inside the egg is the Shadow DOM and everything outside of it is the Light DOM. There's a little wall around the insides and the outsides, right?
Chris: What does this wall do?
Dave: This wall is the shadow boundary or the eggshell, and it prevents the stuff inside from leaking to the outside, such as styles, but maybe even some JavaScript stuff. The stuff inside doesn't just shoot out to the outside.
Chris: It goes both ways, right? From the outside, from the Light DOM, can you query selector inside (elements that are in the Shadow DOM)?
Dave: Uh...
Chris: No. Right?
Dave: No, you can't query selector inside the Shadow DOM but, within the egg, you can query selector things in the egg. You know?
Chris: Yeah, which is cool because then your query selector inside doesn't accidentally select something on the outside either.
Dave: Mm-hmm.
Chris: It's like you can't reach in, but the not reaching out is kind of a bonus there. Can you write a CSS selector from the outside that reaches inside?
Dave: No. There are little tricks. There are a handful of tricks. There's stuff called -- I think we've covered this before -- inheritable styles, font face, stuff like that, stuff that would bleed into an iFrame.
Chris: Oh, I don't know that it would. A font family won't bleed into an iFrame. Well, maybe if you put seamless on it.
Dave: Oh, well, like font-family serif, I feel like that would go through. But maybe you're right.
Chris: What?!
Dave: But maybe a custom font face wouldn't.
Chris: I don't know.
Dave: Okay. Well, anyway. [Laughter] Anyway, so there are some colors and fonts, in theory, go through this boundary. CSS variables are also something that bleeds through this boundary.
Chris: Yeah. Things inherit through it. You just can't select through it.
Dave: Right, so that's something I think we can -- I don't know. I think there are things that go through it.
Chris: That's good, people. This is on purpose, Sam. People set these things up in Web components because they want that. Maybe they call it encapsulation or scoping or whatever. It's really unique. Browsers can do it. No JavaScript framework can really do that. If they pretend to, it's because they fake it somehow or something. But this is real, true kind of encapsulation and it's been desirable for a long time, like, I want to make this component. I want to be sure that it's easier to author, theoretically, because I'm not so worried about outside influence. And it will work in adversarial situations because of that encapsulation. It's stronger by itself. It's kind of a good thing.
We've critiqued it a thousand times on this show because there are problems with that encapsulation, too. It's hard and cumbersome to work with sometimes.
I do want to also point out that it's not just a Web component concept. It probably comes up the most for Web components because, for the -- well, not the first time, but for a big one, you can author it. You can make your own Shadow DOM, but it's not totally unique to existing in browsers. Another kind of Shadow DOM is, imagine something like a color picker, a native color input, or a file picker or something. If you inspect that in Web inspector, you'll just see input type equals file. It'll just be there and you're like, "Hmm."
But, clearly, there's some stuff in there. There's a button and a file name sitting right next to it, but you don't get to see that. Well, guess what. It's because it's inside a Shadow DOM.
Dave: Mm-hmm.
Chris: It's locked in there, so the browser already had this kind of existing concept of, like, hiding some implementation details of things away from you, the developer. Then it would come up in SVG a lot too because, for example, there's this use element that I was hot on for, like, years. Which is like, set up these SVG symbols and then use the symbol. Well, when you use that, it would clone the symbol and put it inside a new SVG element. If you looked in the dev tools, guess what it was. It was in a Shadow DOM. That's how the browser implemented it. If you're aware of that concept, it is literally the same thing.
Dave: Yeah. The thing about Shadow DOM, too, is you can pass Light DOM into it via this thing called slots. In Web components, there are templates and slot are kind of part of the same API. So, the Shadow DOM is able to render Light DOM content within it. That's what makes it kind of different than an iFrame because, in my brain, the Shadow DOM is a little fence around your code. Stuff doesn't go in and out unless you explicitly kind of have a way to do that. But you can't pass content into an iFrame. There may be a way with source doc or some weird thing but, anyway, you can't pass content into an iFrame, and that's where Shadow DOM allows that, so that's kind of cool.
Chris: Yeah. Right.
Dave: I think it's misunderstood because it's confusing. If you're confused, yes, because it's confusing as hell. It's weird that we can make these untouchable pieces of code but then you can see it in your Web inspector but it doesn't behave like the rest of your code. That's weird. It is weird. But I think I say in my talk, this was very immature stuff and it's finally kind of mature, so we can kind of finally--
I think it's ready for broader audiences now just in the year 2021. Until last year, I don't think it was a broad tool. I know some places like Salesforce have been building design systems in Web components since 2018. Red Hat has their PatternFly elements. They've been doing it for a long time. So, people are doing it, but I think, for mass consumption, it was only until very recently.
Chris: Yeah. We'll see more of it in coming years, for sure. When you don't need to framework-ize them, I think that will be even more compelling to see stuff in it because the story then has been, though, even though these are Web components, we know those don't solve all DX problems, so you can put a React component over it or inside of it, or something, which is very weird.
Dave: Mm-hmm.
Chris: I think maybe we'll see less of that because it'll be like, "I don't know. Just use the component. It should be fine."
Dave: [Laughter] Yeah. No, you kind of -- one quote I have ascribed to you, Chris, is "Web components are the only thing with Shadow DOM." React, Vue, and Svelte don't really use it right now.
Chris: No. They'll fake some stuff like scope styles, but they're not real Shadow DOM.
Dave: Yeah. I'm just kind of thinking they could, in theory, do that. You could make a shadow root [laughter] like React component that just only operates in the shadow root. It's probably going to mess people up but, in theory, you could use that.
I wonder. That's kind of funny, too, all these style components, all these styling tools we have for scoping styles and stuff could honestly kind of be shadow stuff.
Chris: Yeah, maybe, but I prefer the scope styles, especially because Miriam, I know, is working on it.
Dave: Mm-hmm. Yeah, yeah.
Chris: If you could just bring scope styles to just regular CSS, then that's what I want, so bring me that.
Dave: Yeah. [Laughter] I told her, "You know, just do what Vue does. Put Vue in the browser." [Laughter] That's more or less, I think, the original intent.
Chris: But they won't have to because I think Vue adds data attributes or class names or something.
Dave: Yeah. Yeah.
Chris: So, like, don't do that.
Dave: Don't do that.
Chris: But do otherwise what that does.
Dave: From the programming, ergonomics. Bring that ergonomics in. That's what I want.
Chris: Yeah! Mentally, to me, remember 100 years ago there was a prototype in the browser of this and the idea was that you would put style with a scoped attribute on it inside a DOM element. It could be in a div.
Dave: Yeah.
Chris: Then those styles just apply to that div and do not go above it.
Dave: Mm-hmm.
Chris: There was something so beautifully ergonomic about that. It just made sense.
Dave: Yeah.
Chris: And that just died, for some reason. I still think of it because I'm like, "That was clever. That was a good way to do it."
Dave: It worked, and then -- let me see here. On my wheel-o-blame [hitting the wheel dividers]--
Chris: [Laughter]
Dave: Safari! Hey!
Chris: Oh, yeah. There you go.
Dave: Killing it. Killing the cool stuff.
Chris: Good stuff there. This is just deep in the weeds, so ignore us from here on, Sam. Think of this, Dave. Let's say you're going to use Vue or Svelte or React or whatever JavaScript framework to handle your DOM for you because it's got some DOM handling stuff built in. Then you put a Dave dash button in there, a native Web component.
Well, when you tell that JavaScript framework to render that to the page, you've got to be a little careful if it's going to chew up any of the attributes on it or not because some of those libraries are like, oh, if you put data size equals small on it, it'll be like, "Oh, I see that belongs in the DOM so I'm going to put it there."
Dave: Mm-hmm.
Chris: Class names belong in the DOM. Other ARIA controls belong in the DOM. But if you just pass in size equals small, it'll be like, "Oh, no, that's a prop, not an attribute."
Dave: Ah, yeah, yeah.
Chris: "I'm just going to disappear it from the DOM when I render it totally because that's not what you meant. You don't mean for it to show up in the DOM." But in a Web component, you'd be like, "Excuse me. I totally did mean it for it to be in the DOM. If it's missing, it's not going to work, so can you not do that, please?"
Dave: Like Vue will if you have - whatever - size is big equals false, or something. That's a terrible name, but it'll just delete false values. It won't render false values.
Chris: Oh, there's that too.
Dave: I wonder if there's an issue there if you had a Boolean prop, you know, Web component.
Chris: Or if the thing has a dash in it because Web components are uniquely identifiable because they must have a dash in them.
Dave: Mm-hmm.
Chris: You'd think these libraries could be like, "Oh, this component has a dash in it, so I'm going to leave all the attributes on it."
Dave: It would be cool. [Laughter] Yeah, I haven't--
In theory, Vue -- React is kind of the big outlier for letting you use Web components.
Chris: Yeah, I would say so.
Dave: I think it's all about this props situation. Vue, Svelte, they're very Web component compatible. Angular, too, because Polymer very much looked like Angular back in the day. But I think there's actually -- remember, Scott Jell was working on an Angular site and wanted to use Web components? Just had a bit of a problem getting it all working, but I think it does work, but it was not the best, easiest experience.
Then there's stuff on the Web component side, like if you write your stuff in Stencil; you write a Web component. Stencil (from Ionic) is smart enough to kind of, like, "Oh, you want to spit this out as a React component. We can actually make that a React component." You can author your Web components and then spit out React - or whatever.
Chris: Mm-hmm.
Dave: There are different ways to solve these fit problems. But it would be cool -- I don't know -- just to see where the next wave of frameworks are that might just support Web components out of the box. You know?
Chris: Yeah. The next wave. Let's have them. I bet Astro does a good job, but I won't derail us like that.
Dave: Well, and Astro, I guess one problem, too, is a lot of frameworks and components have moved over to server-side rendering. Right?
Chris: Mm-hmm.
Dave: You are able to -- whatever -- React DOM to string, or whatever. Web components just got this thing called declarative Shadow DOM kind of like where you write that scope style in the thing. You can write a template inside your Web component, like dave-button, and then I have a template that says shadow root open. Then you can kind of server render. Then it has all my Markup from my template inside there.
So, you can declarative Shadow DOM and render server-side. The browser (Chrome, I assume) is able to pick that up and be like, "Okay. Cool. You gave me a template. I can render that without any JavaScript."
Chris: At all.
Dave: I can render that from the server. Yeah.
Chris: Nice.
Dave: But is it dynamic yet? Not yet.
Chris: Do you process it ahead of time? Probably, right? You have to--
Dave: Yeah. I mean I guess you could pre-process that, but then--
Chris: Or does it duplicate? Let's say you have a Web component that's five buttons and they appear five times on the page. You have to put that template in all five of them?
Dave: Sadly, yes. You have to duplicate the template and your boy, Dave Rupert, commented on the thread, "This is clown shoes," but I didn't win.
Chris: [Laughter]
Dave: I think it's one of those "What's easy?" thing.
Chris: Well, that's fair, and also that maybe a lot of people pre-render it, so they're not hand-authoring those five things. It's just some kind of compiler is blasting that out.
Dave: Right. I think that's it, too, is people are like, "No one is going to hand-author this." Then I'm like, "[Laughter] Actually, Dave Rupert would be."
Chris: Yeah. [Laughter] Yeah.
Dave: You're like, "Yeah, well, we're not building the Web for Dave Rupert," although they should.
Chris: They should.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Netlify. High-five, Netlify. Y'all are always doing cool things.
Have you seen their new deploy previews that has the feedback feature on there that was powered by FeaturePeek, which they acquired? Pretty darn cool way to integrate feedback on deploy previews. Like, "Hey, go take a look at this and leave some comments," or whatever, if there are things that you need to see changed before this goes live. Those things can be configured to go right to GitHub Issues. But that person you sent it to, they don't have to even know GitHub exists. It doesn't matter. That's pretty cool.
I would subscribe to the Netlify blog. They are prolific bloggers, and they talk about this kind of thing on there, but all the articles, they have really high-quality stuff on there. It's not just like, "Here's what's new at Netlify." There's, "Here's what's new in the industry," and "Here's what's new about the JAMstack philosophy," and that kind of thing.
There's an article (just as I look now) about Web Core Vitals, the new big thing that everybody cares about at Google because it's all about Web performance. Well, there's stuff in there about why you should care about it, but why that matters to JAMstack as well - pretty darn cool.
An article here about Nuxt Image, which is great. A lot of these static site generators have really powerful image plugins that take your core image and make all the versions of them and add all the right attributes that are the best things for performance and host them in the right way for you and all that. Some of those things do 50 things for you. It's incredible how it is.
Cassie has got an article about React 18. That's my favorite one that I've read so far because it actually explains what's actually new and you actually need to care about for React 18. There's actually one kind of big change about the render function and how that works with create root now in React 18 that's worth kind of knowing about and, not to mention, that suspense is out of alpha, or whatever it was. That's kind of a big deal because I was kind of using it anyway. Ooh--
Anyway, Netlify is always doing good stuff. They're writing good stuff. They're a tremendous host, so thanks for the support.
[Banjo music stops]
Chris: Speaking of browser stuff, there's this thing called LayoutNG in Chromium that's like, "We're going to rewrite everything," kind of thing, but it's like a year's long super process that's broken into chunks, I guess. I only kind of know this because -- I feel like I should know this, for one thing. We're browser people. We spend all day talking about browsers and sometimes it's a big surprise when browsers are undergoing major changes. I do feel like there is a weird disconnect from the people that write browsers and make these features actually happen for us. Even all that excitement and stuff when they come up, and us developers ourselves. Is it just because they write different languages? It just feels weird. After all these years, it's kind of like, "And then somebody behind the curtain makes the feature happen and we all applaud."
Dave: Mm-hmm. Yeah. Yeah. It's kind of funny because there's a roadmap and there's probably a public thing, but we don't know, unless you're digging. You know?
Chris: Yeah.
Dave: I don't know.
Chris: The point of the chunks of LayoutNG was TablesNG, which just dropped. I published some post months ago, something about sticky table headers and footers and even columns. The deal is you can literally use position sticky on table cells.
Dave: Ooh--
Chris: Even before LayoutNG, which is kind of funky and weird. But if you'd select all the cells in a column and put left zero position sticky, they'll stick. If you select all the table header cells in a header and say top zero or bottom zero with position sticky, they'll stick. You know?
Dave: Okay.
Chris: You've got to think about Z index and what goes over what and how it looks and feels and stuff, and it's tricky to pull off, but it's doable. But the comment was, "This is a bug." The fact that you can't select just the row of T head or whatever to do this, that's the bug. Because Firefox can do that.
Dave: Oh, interesting. Yeah.
Chris: Safari even can do that. It's just Chrome couldn't. It turned out Chrome's tables rendering stuff was way behind and TablesNG was rewrite of tables -- very cool. Speaking of the communication between browser developers and kind of like the outside world or whatever, the other developers, there's a Google Doc that explains it all, which I don't feel like you often see. Sometimes it's a spec or something they point to, but this one is just a Google Doc.
Dave: Mm-hmm.
Chris: I'll have to paste it in the show notes. It just explains all the different stuff. It's not just about making things sticky. It's just, that's what was on my mind because I had just tried it recently, but there's stuff about how borders paint over each other that was different between browsers and stuff. Uh, just kind of interesting, so.
Dave: New table, though.
Chris: New tables.
Dave: Could you imagine working on this code? It was very possibly written in the '90s by like five browser engines ago. You know? It's probably pretty gnarly.
Chris: Very, I'm sure. But I'm sure some people kind of find it fun. You know? Like there is a very clear spec that we need to follow and there are clear outcomes and it kind of has a visual nature to it, so you can write some code, refresh the browser, and kind of see did the code do what it's supposed to do. Are all these surely 20 million edge cases [laughter] accounted for?
Dave: [Laughter]
Chris: You know?
Dave: Yeah.
Chris: But it's like that kind of developer work could be satisfying that this is a story I need to make happen. There's a clear path from nothing to success and I can achieve it.
Dave: Well, and I'm sure there's so much that's better. Even just text layout passes and just even micro crap we don't even think about. You know?
Chris: Yeah. Yeah.
Dave: That you're just able to be like, "I'm going to put the new text machine in there." You know?
Chris: Yeah. Yeah.
Dave: We don't pick up on it, but that's amazing for the browser. [Laughter] You know?
Chris: You know it must feel like -- like in CodePen, we still have some jQuery. Not everywhere. A lot of pages don't have any at all, but there's legacy stuff.
Dave: Mm-hmm.
Chris: It's a big app and there are a lots of areas and some stuff is still in jQuery and some stuff is rendered by Rails still, and stuff. We're moving away from that and it's not like the top priority. It's not like this week we'll remove this amount of jQuery. That's not how we think. We're like, "Let's work on a feature. Let's work on something somebody cares about." But our goal is to reduce that stuff.
There was a cool mockup for a part of this future thing that we're building and it turns out, hey, we could actually backport that to something of today. By virtue of doing that, people get the new experience sooner and it's written in our new stack, not the old stack, so we got to rip out old code. Doesn't it seem like it would feel like that?
Dave: Mm-hmm.
Chris: The users don't care about our ripping out old code, but I do. It feels good.
Dave: Yeah.
Chris: And I'm sure, to these developers, it feels good to rip out code that nobody thinks about, nobody touches, with new code that's probably better tested and is more in the minds of developers today.
Dave: Yeah. You just have some helper library that makes it so much easier and that's just that easy. Yeah. What's your process -- switching gears -- for CodePen? When you identify, "Oh, that page is old. That template is old," what do you all do? Does it just go in the "that would be nice to fix it up" bucket, or does it get on the roadmap?
Chris: Yeah, it depends if there are multiple -- you know things tend to get done if we could point to multiple things that would all benefit from the feature - kind of thing. There was some payment-related work that we wanted to do for a long time, but it required some data changes to shore things up in a better kind of back-end data-driven way. And there's, like, "Hey, maybe we could improve our APIs and use some new technology that we're moving towards anyway."
And what if we could Reactize this form and make it more reusable? And we have some pro members that are incorrect in our database that we need to correct, and that would be an opportunity to reach out to them and tell them what's wrong with the account, apologize, fix it, and stuff. There are five things at once. That's actually not a feature we would run away from. That's one we would pick up because it's like, "Oh, this is going to have benefit all over the place," whereas I don't think anybody would just open a page and be like, "That's old. Let's new it." [Laughter]
Dave: Mm-hmm.
Chris: That's not enough to act on it.
Dave: Yeah. Yeah.
Chris: For example, maybe you don't even know this about CodePen because it's a Tier 2 feature, I guess. Unless you used embedded pens a lot, you can stylize your custom pens by adding custom CSS to them or picking a dark or light theme or whatever. But we also have this whole area of the app called the Embed Theme Builder, which is a thing, like a no-code version of what color do you want that bar to be? What about the buttons? What about the border? What color do you want the border to be?
Dave: Mm-hmm. Mm-hmm.
Chris: You select all these options, then save a theme, and it goes into a database. It's one of the pages on the site that is just Rails everything, like jQuery powers these little dropdowns. Rails renders this output. It doesn't use any of our design patterns that we've built up. This page is begging, begging to come into 2021 with us.
But does anybody -- do people deeply care about this page? Is it highly used by users? No. To spend some time on this page, yeah, it'll be a little satisfying but not as much as, you know, the work is just very A to B. Rewrite page. Deploy. There's not a lot of deep benefits to this page, so it's not even on the roadmap at the moment. It absolutely will get done because something else will kind of force its hand.
Have you ever had a feature like that where you're like, "Oh, but we want to put this routing at the root and this page is still an old-style page," so it's a blocker for something else we want to do, so we've got to knock over that page first. Then we can do this other thing. That's likely what it's going to be. It's not going to be, "Let's do this project." It's going to be like, "This is a blocker for another project."
Dave: Yeah. It would be like, "We're going to change from CodePen embed from an iFrame to a Web component," or something.
Chris: Yeah.
Dave: Then you're like, "Okay. That's like, we've got to do more."
Chris: Yeah. That could be it, and I think there would kind of be some benefits to that.
Chris: [Laughter] Twitter literally did that at one time and then was totally backed off. I remember talking to a dev from Twitter about it. Which basically they didn't even remember that period because it was so short-lived and didn't work out. But I remember it being clever at the time.
Dave: [Laughter]
Chris: Because it was like iFrames have an inherent cost. It's a cost in, like, white frame jankiness. It's just like the browser has got to spin up a little website in there with all that kind of flashy grossness. I'm sure they tried to do a good job, but it's just not as good as something, a native development that's on the page. Web components are just faster. Even if what's inside of it is largely the same, it's going to feel better as a Web component.
Dave: Even just the post message requirement. You have to hook into the main page and hook into the element to measure it to get the height. That's jank.
Chris: Oh, that's old as time, that one. How big is the page that I'm iFraming? Could the iFrame on the outside be as tall as it is? That's a pretty common one. Yeah, you've got to post message back and forth to even get that to work at all. Or unless you're on iOS, and then the iFrame is automatically as tall as the content inside it and cannot be moved up or down. It's absolutely awful.
Dave: Oh... How could that go wrong? Yikes!
Chris: I don't know why that isn't more talked about as the worst thing ever, but it is to me, especially as somebody who has user authored content in iFrames, which we cannot control. It turns out the answer is largely to just put it in a div and size the div.
Dave: Okay.
Chris: Then if the iFrame overflows it then so be it. Then scroll it, which generally works fine because the iFrame will pass the scroll event up to the parent and scroll it - thank God.
Dave: Yeah. Yowzers, though. Yowzers.
Chris: Yeah. Yowzers, indeed.
Dave: [Laughter] When your core product is a series of iFrames and then you're--
Chris: Yeah, it kind of is. There is literally two iFrames deep in an embed because the whole thing is in iFrame and then the preview of the code you wrote is an iFrame in there.
Dave: Yeah.
Chris: It's just how it has to be. I think, performance-wise, we do pretty darn well with these things. We take that seriously. There's no jQuery in there. There's no tracking scripts. There's no -- it's just as light as can be. We write it in vanilla JavaScript what very little we needed to do. It's pretty nice.
Dave: I remember learning about iFrames in about 2001, and I was like, "Wait. I can put a frame inside the page and control it? I can just link to a page inside the frame?" I abused the hell out of it, but it was so magical when it came out. I remember almost the day I learned it and it was just--
Chris: I wonder. What day do you think iFrames drops? I have no idea.
Dave: I don't know. I don't know.
Chris: But I worked at WuFoo for a long time. Not for a long time. For a short time, but it was formative for me. Their business model was iFrames. If iFrames didn't exist, I don't know. That would have been a much weirder world. The point of it is, "Make a form. Put it on your website."
But if it's not an iFrame, there are going to be so many problems with that that could go wrong. Whereas an iFrame, it's just like, oh, it looks perfectly beautiful on your website. Great.
Dave: Yeah. Oh, okay. First introduced by Microsoft Internet Explorer in 1997. Standardized in HTML 4.0 transitional.
Chris: Dang. I was definitely smoking a cigarette behind the bowling alley in 1997, so.
Dave: [Laughter] I was, yeah, running around with homeless Kirk and just driving around going to punk rock shows, but hey. Yeah, I think it was probably '98 or maybe even 2000, 2001 where I figured it out.
Chris: Right.
Dave: It was just like, "This is awesome."
Chris: Isn't one of the funny legacy things that they're 300 pixels wide by 150 pixels tall unless you--?
Dave: That was huge, you know, on my 680x480 display.
Chris: That would be one of those UA styles that I think you all could just change it. I don't think there are compatibility issues with that, although you'd have to ask Mike Taylor. But I feel like they could just be 100% wide. Why can't we do that?
Dave: Yeah. I wonder. Yeah, it's kind of funny. There's this interesting -- I should maybe pause this. We can rip this out if it doesn't come out well.
Some people who use screen readers, you know, they're fully blind, so they literally just rip the display off their laptop and they just use a keyboard, right? The display could be totally broken.
Chris: Yeah.
Dave: And so, when their browser shows up on the analytics, it's like 300x150 (or whatever) because they don't have a screen even, you know?
Chris: Oh, right.
Dave: They're basically like, I don't even have a screen. Most people use a full screen and have some kind of vision, but it's interesting. I hadn't really ever thought of that.
Chris: Me neither.
Dave: They just literally turn their screen off and it doesn't have anything. I'm impressed. I don't know. But I think it creates some problems because not everyone figured out how to -- I don't know. You make some assumptions about things that small. Anyway--
Chris: This makes me think of a story worth telling about CodePen embeds and iFrames. This came from Heather Burns who wrote a blog post about this for Equal Entry, which I think is probably experts at accessibility, and you hire them to do stuff - probably.
Dave: Very good.
Chris: They had emailed us about CodePen embeds because there was some problem. They were like, "This fails some accessibility test," or something.
I was like, "Well, that's important to us. We're going to look into all those things." There were a bunch of little problems, and we were able to knock them over one by one. They were pretty pleased with the outcome, so that was cool.
One of them is that you're tabbing through a page or through the -- it's not always tabbing, right? You can explore all kinds of ways in a screen reader, by region and header.
Dave: Headings, region, buttons, links, all different kinds.
Chris: Image you're tabbing through. You will be sent into a CodePen embed iFrame, like this second level deep to explore what the result is. I think we maybe had that turned off for a minute because it would be kind of a focus trap. You know iFrames can have that effect.
Dave: Mm-hmm.
Chris: But it turns out you tab through an iFrame to the bottom. You kind of come out the other side of the iFrame, so I think that's generally how it works. That's good. I think we removed that so you can get in there now, but some embeds have just a ton. We have no idea what's going to be in that iFrame. It's user-generated content.
So, we implemented this thing where if you're tabbing through an embed -- have you ever seen one of those "skip to content" links at the very top of a webpage? Surely you have. You probably implemented it 100 times.
Dave: Yeah. Yeah.
Chris: Sometimes, the recommendation is to make it visible once it's tabbed to, but it's otherwise invisible. You know what I mean?
Dave: Mm-hmm.
Chris: Yeah, we did that for the embed. As you're tabbing through an embed, you'll tab onto a button that says result, which is the toggle for turning the result on and off. If you tab one more time, a button will just appear out of nowhere, visually. It was always there for a screen reader, and it will say, "Skip results iFrame." All it does is move your focus down past the iFrame.
Dave: The iFrame.
Chris: And allows you to the other things, do the other stuff. That way you have the opportunity, at least, to avoid tabbing through that entire iFrame.
Dave: Right. Well, you know that's cool because, yeah, those things can be miles and miles long. It could be really bad.
Chris: And they were happy with it and it seems cool to me. It didn't require any advanced, fancy handling of focus and stuff because it's a link and it links to another link that's past the iFrame. You know? [Laughter]
Dave: Yeah.
Chris: Not all accessibility problems have an HTML solution. I feel like accessibility is often very weird like that, although you know ten times more about accessibility than I do. Sometimes there's like, "This color should be 5% deeper." Okay, problem solved. It's like a one-line fix and it goes a long way.
Then some accessibility problems are like, "You need to trap the focus in this modal," and it's the hardest problem ever. Good luck.
They go from very easy to very hard very quick.
Dave: That's another talk of mine called "Log Jams." [Laughter] Not all issues are created equal. You can't just hand a bucket of accessibility issues to a developer and be like, "Good luck." You almost have to break them up by difficulty and start people out on easy stuff like good first issues. You know?
Chris: Yeah.
Dave: Then that's probably your contrast, your button labels, your ALT text, and stuff like that. Then move people up in the, like, challenge domain.
Chris: Yeah.
Dave: Just progressively increase the difficulty. That's stuff I don't think people really understand or even not even just challenge. ALT text, almost anyone can do that. It almost doesn't even need a developer. But then you get into contrast. Well, hey, now you need kind of a developer and a designer involved, working together.
Chris: Right.
Dave: I don't think my dudes--
Chris: Yeah. You can't just go around being like, "I'm just going to darken this color," and it's a one-off darkening that's not part of any system. Yeah.
Dave: Yeah. That's not good. that doesn't make happy coworkers. [Laughter] So then, all right, well, cool, and then now -- then you get into the cognitive issues, like, sometimes you put a button (like a toggle) and it controls stuff above it. If I click the toggle -- as a non-sighted person or even as somebody with cognitive disabilities like you could think autism, MR, or something like that -- you're kind of like, "Well, what did that button do?" I have no idea because what you changed was maybe offscreen even.
You have these cognitive issues where the thing below the thing -- so, that's a whole UX refactor. You have to redesign the component entirely, so that's a huge challenge level. You know? I think people don't quite put that into consideration.
Or if somebody is like, "Okay, horizontal scroll is bad." In my experience, different [laughter] accessibility people will give you different opinions on that. So, you kind of have to go with what your team says. You do horizontal scroll. If you have to rip that out, that changes everything. You know? So, anyway.
Chris: Hmm.
Dave: It's all very interesting.
Chris: It's interesting how the easiest accessibility problems to detect are somewhat mapped to easiness to fix. I know there's nuance that you talked about with looping in designers and stuff but, yeah, it's those ones that are hard to detect that are hard for a reason.
Dave: But the good news is Glenda Sims (@goodwitch) did some Deque studies and stuff like that, looked at all the Deque reports, axe reports, and stuff like that. From what accessibility tests can detect, it's only about 20% of accessibility errors, but that represents something like 57% of all accessibility problems. So, it can only detect a little bit of accessibility, but the bulk of accessibility issues on a website or an audit are the testable ones, so the majority.
Then if you add in this kind of manual testing that some of these things have -- we talked about this before, I think -- if you add in manual testing, now you're into this 80% range. That's really pretty cool to think, like, "Oh, I could be 80% accessible if I just kind of follow what axe dev tools or accessibility insights is kind of telling me to do."
Chris: Yeah.
[Banjo music starts]
Chris Enns: This episode is brought to you by Dexecure, a company that saves developers time by automating mundane tasks that y'all hate to do but have to do. Images, JavaScript, CSS, HTML, fonts, and third-party assets: Dexecure does the optimization with just one line of code, and you can focus on what you love doing; building new and exciting websites.
It's super-easy to implement. Just one line of code needed for integration, or they've got a plugin if you're using WordPress. No matter the device or browser type, Dexecure will always have the best version of your website.
You can visit dexecure.com/shoptalkpodcast for one month free when you sign up for any basic or pro plan or try it out for free with their free account. Our thanks to Dexecure for sponsoring this episode of ShopTalk Show.
[Banjo music stops]
Chris: I've got one to throw at you just because it feels thematically related, in a way, too. I saw one of those classics on Twitter where it was even my fault because I retweeted it and the pen had kind of like a marque bar at the top of it, so it moved. You know?
And a tweet reply was, "Hey, be careful, please." Like, don't just tweet stuff like that. You've got to put a content warning on the demo because it has movement and it could cause problems. Too much movement (I've heard you say) gives you sickness.
Dave: Yeah. Well, vestibular disorders is kind of what you're looking for.
Chris: Yeah.
Dave: Yeah.
Chris: Fair enough, right? There is a thing in CSS called prefers reduced motion. I think you can tap into it in JavaScript, too. It's a media query that asks your operating system or whatever the next highest power may be, I think, if their setting is to prefer reduced motion, and it gives you a chance to honor that. Is that a good API in the world? Absolutely. Of course, it is. That's great. You should do your work as a developer to honor that setting.
I think of someone with this disorder, if it's a problem for them, it's them versus the Internet. You know? It's like them versus millions and millions of websites that didn't know about that API, that don't use that API, were created before that API ever existed. The odds are against you, sadly. Doesn't that suck?
Dave: Mm-hmm.
Chris: If it's very important to you, what are your options? Are there browser extensions and such that will just save you from that? Rather than -- like, they could inject stuff into the websites, star selector animation none-important. Don't do it. Don't show me anything. Is that a thing that people use or is it just not thought of?
Dave: I don't know. That would be kind of cool. This kind of gets into light mode, dark mode for me, too. It'd be cool if I could control it at the browser level, like turn it on and off. You know? I guess I can in dev tools, but more like if I could turn on a no barf button on in my extensions or something like that, that would be pretty cool.
Chris: Yeah.
Dave: The problem with wiping -- that's the nuclear option, right? I have to wipe out all animations and stuff like that.
The important thing to realize is some of this stuff is not -- if you fade something in, like an opacity transition--
Chris: Right.
Dave: --or a little bit of movement--
Chris: It can literally break stuff. If you have one of those pages where you scroll down and everything is fading in on you.
Dave: Yeah.
Chris: Well, if you turn off all animations, maybe you get a white page. That would suck. I've definitely seen the snippet I've seen is animation timing or animation duration, I think it is. It's like 0.001 second important.
Dave: Oh, that would be--
Chris: So, rather than removing the animation, you make the duration instant, essentially.
Dave: That'd be cool. Yeah, I mean that seems like a good move.
Chris: And it also matters because JavaScript can tap into those APIs and say, "On animation end, then show payment button," or whatever. If you wipe out the animation again, that event never fires. You broke the website.
Dave: Yeah. Unfortunately, you create an other-ism thing, like if you're adding--
Chris: Oh, I see.
Dave: I don't know. We could take the same approach and be like, "Why don't screen reader people just disable JavaScript?"
Chris: Yeah. We built another Internet for you over here.
Dave: We built a different one for y'all.
Chris: Ah...
Dave: The same with, like, I think about video games a lot. You know? Accessibility in video games is all about offering options to the user. Let them control the text size. Let them control subtitles on and off. Let them control different things.
Chris: Yeah, a lot of settings in video games, right?
Dave: A lot of settings in video games, but that's because they're more advanced. [Laughter] You know the whole thing is just a marionette of settings, basically.
Chris: You're about to spend about 60 hours in the thing whereas you're about to spend about 40 seconds on a website.
Dave: Right, and so I'm not going to configure my Best Buy settings just because I'm there. Right?
Chris: Right.
Dave: Like, "Oh, man. I love Best Buy."
Chris: That should be the browser thing.
Dave: That should be on the browser level, I think, personally. I think there should be a series of settings that I can even turn on and off for that experience right there. That would be cool if that was a level of something I could do. Yeah, I don't know. Nuclear animation dismissal sits kind of wrong with me.
Chris: Right.
Dave: The same as wrapping every animation in prefers reduced motion because I may want to turn it off because, hey, that weird website that goes diagonal when you scroll makes me want to throw up and gives me a headache.
Chris: Little wavies on stripe.com are chill or something.
Dave: Yeah. I don't want to see those little wavies on stripe.com or something pulsing or something like that. That would be kind of cool. Yeah.
Chris: Yeah, the nuclear level stuff. You'd only do it if you were -- I don't know how you classify these problems, but I imagine there are some people who have it really bad who really don't want to see anything move.
Dave: Some people have seizures, man. I mean if you think about it that bad. Stuff starts moving on the page; they have a seizure. They're out for the next hour.
Chris: That's very, very, very bad.
Dave: You took an hour of somebody's fucking life because you wanted to be cool on the Web. That sucks. You know?
Chris: It does.
Dave: I'm not cool with that. [Laughter] So, anyway, a photo will tick, like if you're flashing lights or gifs or whatever, that's bad too. That can be used really in sad situations, but yeah. Me, I just get a headache. Feel a little barfy for a bit. Maybe take some Advil. I'm fine.
Chris: Yeah. Yeah.
Dave: But to be honest, I don't think I have anything wrong with me, Chris. I maybe had a concussion in college, but I don't know if that's impacting it. I'm fairly neurotypical. You know? I'm just getting older and, when you get older, the crust that -- whatever -- the stuff in your vestibular canal, which connects your ear to your jaw, which is where all your balance comes from, as you get older that stuff gets harder, right?
Chris: Hmm.
Dave: That affects your balance - when you get old, old. That's why old people fall down is because they don't have good balance because that liquid in between their ear and their jaw hardens up.
Chris: Geez! Yeah.
Dave: I'm not like I need assistive technology. I'm just getting kind of old, and in extreme circumstances, it affects me. For other people, in non-extreme circumstances, it affects them.
Chris: Yeah. Yeah.
Dave: But there is some nuance and you've got to test with users and stuff like that. But if you just fade something in gently, that's not a big deal. But if you slide something in from the side, that's like, "Geez, dude."
Chris: That's worse. Yeah.
Dave: Yeah, and some of that is just because you're attacking somebody's lizard brain where it's like, "If it's moving, I'm going to look at it," right? [Laughter] It moved. I have to look at it.
Chris: That's exactly it. That's why it's so effective and can be in the vein of not just a joke.
Chris: Remember I was bitching about tables the other day and how you can't animate the height of a table cell where it just ignores you? I was putting in that animation not because I'm like, "Oh, it's animation time! Fire up the fun machine! Woo!"
Dave: Yeah.
Chris: It was because I was clicking delete on a bunch of table rows and they were instantaneously deleting and I wasn't quite sure if it worked or not. It didn't tap my lizard brain like I wanted it to. It didn't slide away or have some kind of subtle movement that says, "Oh, success. That row is being deleted."
Dave: Mm-hmm. Mm-hmm.
Chris: In the end, we ended up just nuking the table semantics altogether. It was kind of questionable whether it should have been a table or not, anyway, so I didn't miss it. But I was like, "Whatever." They turned into just divs and the divs had all the animation possibility in the world.
We've got to wrap this up because it's a hard stop edition, but I want to shout. I had one more thing in my note I was going to ask Dave about: WAAPI, the Web Animation API, and if Dave is using it and stuff or not. We're not going to go there, but I want to know if you're going there. Are you using it, people of ShopTalk Show? Are you into it? Do you use your prefers reduced motion API there in order to not run it? How do you feel about it? What's up with WAAPI and you?
Dave: I want to know. I'm currently not on it, but I think the browser support just got there, right? So, I think we're kind of here.
Chris: I've used it twice recently and I was like, "Dang, this is cool." I was going to -- my quip is that it felt like inline styles for animation. When you're writing in kind of like a JavaScript syntax anyway). You can just slap a little style attribute on something if you have a one-off. Well, sometimes animations are one-off. It's a little bit common and you can just slap a WAAPI on there, and it has a nice API for when I'm done with this animation.
Dave: [Laughter] WAAPI--
Chris: Slap a WAAPI, baby.
Dave: New episode titles.
Chris: [Laughter]
Dave: Slap a WAAPI. All right. [Laughter]
Chris: Okay. See ya later.
Dave: Hey. We'll wrap it up. Thanks, everybody, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.
Join us on the Discord, patreon.com/shoptalkshow. That's how you get in. We would love to have you there. It's fun. It's just downright fun.
All right. Thank you. Chris, do you got anything else you'd like to say?
Chris: ShopTalkShow.com.