Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--I really don't -- I'm drinking coffee and water, so going to have a bathroom explosion--Rupert. [Laughter]

Chris Coyier: Ooh!

Dave: With me is Chris--comfortable in the booth--Coyier.

Chris: How does that work? I had the same thought. I'm like, normally you take care of those things before the show.

Dave: Hey.

Chris: That's a gross way to start the show. Let's do something else.

Dave: Uppers and downers, man. That's how Elvis died.

[Laughter]

Chris: Yeah. Yeah. Yeah. Anyway, you know, in the last couple of shows, we have not done as many user -- you know, listener submitted questions as we would like. They're coming in at a decent clip these days, but please -- you know, and always know that you can go to ShopTalkShow.com, click that Ask button, and send in a question, or it could just be kind of like your thoughts on something and kind of like a request for a topic kind of thing, like, "What do you think about this?" That's kind of enough. I like the question-based ones, too. But if it's just kind of like it would be nice to hear us talk about that, that's cool too because that's what we end up doing anyway. [Laughter]

Dave: Well, and if we get a lot of "You did it wrong," too, send those in, too, and highlight points we missed. I think that's fine and we'll try to address it in later shows because I always forget. If it comes through Twitter or something like that, I forget, like, "Oh, I forgot to mention whatever."

Chris: Sure.

Dave: "Web RTC has some weird thing," so anyway. But I love seeing these questions come in, so it's good. We had a good, nice little durf there. Now we're back and the question hopper is getting full.

02:04

Chris: Yeah. There's one. Let me just read the question and you tell me what the term is. I might even stop the question halfway through to have you guess at what the term is because I think it's been named but I can't remember the name of this phenomenon right now. It's related to JAMstack in a way, right? JAMstack, you prerender stuff. That's pretty much like the one thing JAMstack asks you to do. Otherwise, it's pretty un-prescriptive, you know. It's like prerender some stuff and throw it on a static host with a CDN. You know?

Anyway, so here's the question. Let's say you have a site that uses a JavaScript framework but it also uses statically generated HTML. You're doing kind of both, which is actually getting a lot more normal. You go to the URL and it loads super-fast because it's already got the HTML. Aw, sick! Good job.

You see everything, but then there's this, like, moment in which the page is like, "Well, I already have that but I'm a JavaScript app, so I'm going to boot up the JavaScript too. I'm going to request a bunch of JavaScript. I'm going to execute a bunch of JavaScript. The JavaScript is going to kind of take over because there are advantages to that.

As much as people like to scream and shout that maybe there isn't, I think there kind of is. I think it's kind of nice sometimes when JavaScript takes over click events and does a really fast second-page load. I kind of like it. Not everybody does, but not every site deserves it or needs it, but whatever. It's kind of nice, so okay.

But there's that moment in which the page is rendered but the JavaScript is executing, which kind of stops things. It can stop the main thread. There's a moment where the click handler is blocked or whatever. What do you call that in-between phase?

Dave: Yeah, I mean it's kind of an uncanny valley--

Chris: Yeah.

Dave: --because it looks like a webpage.

Chris: That's … from you too. Yeah.

Dave: It looks like a webpage, an interactive webpage, but it is not an interactive webpage. I think the metrics people are tracking are time--

Chris: TTI?

Dave: TTI, time to interactive, or the new one is kind of first input delay.

Chris: First input delay? Yeah.

Dave: My quintessential example is The Verge, which everyone is so hard on The Verge, but it's a blog. It's a very popular blog, but I can load up The Verge and the search input isn't active for about a good 25 minutes, and so it's always noticeable to me, that one little piece.

Chris: Yeah.

Dave: When people are talking about, like, interactive but it doesn't work, that's my go-to example.

Chris: That seems right. I think uncanny valley is a good word for it too. Now, that's that robotics term where people are happy, happy about little robots with, you know, square faces and bows in their hair and they kind of get it when a robot exactly looks like a human, like Battlestar Galactica or whatever.

Dave: Mm-hmm.

Chris: But they don't like it when it almost looks like a human but not quite enough. We reject it. We're like, "Ew! Ew!" That's the uncanny valley.

Dave: Yeah, it's hideous when it's--

Chris: Yeah, it's hideous.

Dave: When it's not full fidelity.

Chris: Yeah.

Dave: Very rudimentary is like, "Oh, yeah, that's cool." Then when it's very full fidelity, you're like, "Yeah, that's cool."

Chris: That's fine.

Dave: But that uncanny valley where you're just like--

Chris: Mm-hmm.

Dave: "Oh, what is this monstrosity?" You know?

Chris: It's funny and I think it's cool to coop that term for a website, so that's cool. I think the process itself is referred to as hydration when the site is there.

Dave: Yeah. Yeah.

Chris: Yeah.

Dave: That's when basically the static, dried out chunk of website is delivered then the JavaScript comes through and hydrates that--

Chris: Right.

Dave: --with new data or interactivity event….

05:55

Chris: It brings up fascinating stuff like is there a world in which that browsers are kind of like updated in some kind of way that is hydration friendly? Just leave the site alone for a moment because usually these sites that are hydrating, the links in them do still work. If the JavaScript never loaded, the href still point to another URL that also is prerendered and stuff, so the hydration is kind of optional on these sites. It's just nice when it happens that, if that became popular enough that browsers could be like, "Well, we can speed up hydration," or something. "We can load all the resources and then, within a couple of milliseconds, flip on the JavaScript." I don't know if that's possible or not but it occurs to me that it's like the reason that hydration sucks and uncanny valley sucks is because of just the ways that browsers work today.

Dave: Yeah.

Chris: It doesn't have to be that way forever.

Dave: I was going to say, there are a few things coming to the Web platform. The scheduling API, which is--

Chris: Oh, I don't even know this. What's this?

07:01

Dave: This is some work that stubbornella--

Chris: Mm-hmm.

Dave: Nicole--

Chris: Nicole Sullivan.

Dave: Nicole Sullivan. I was like, I had it, but anyway. Nicole Sullivan is working with the Facebook React team and it's this idea that you can assign high, medium, or low priority to scripts, events, or something. I'm not sure what the exact API is, but it's this idea that you can basically prioritize things like this has to go through the CPU first. Please do this little chunk first.

Chris: Hmm.

Dave: There is maybe a future where you can say all the buttons that got painted, those are high priority items. They need to be interactive first.

This is Dave--too many farts in the fart machine--Rupert talking. My optimism that this is going to work is very low because everyone thinks their thing is the most important thing. You know?

Chris: I know. Fair enough. I could see it going the other way.

Dave: Like, does the search need to work? It's like, does the search need to work or does the content need to load? I think probably the content needs to load. Well, now you have to load the whole templating machine. That has to be way before any kind of event, so I don't know that scheduling is going to buy us a million--

Chris: Yeah, maybe not.

Dave: --percent improvement but there is a post over on the Facebook engineering blog that kind of outlines the work they're doing there because I think they're contributing to Blink a bit, too, for this. But it's the idea that you click a button and nothing happens for a bit because none of the events or anything are even loaded yet, so they're trying to solve--

Chris: But it remembers or something?

Dave: Well, or the CPU is throttled, so it can't do those tasks or whatever. It's doing other work or behind the scenes repaints or whatever. But for me, it's like, how bad did you mess up a button that it doesn't work? But I think, also--whatever--the ship has sailed on JavaScript - I think we've said before. People need this, apparently, but my optimism that everyone is going to be like, "Yes, this is a high priority thing," "Yes, this is low," I think that's low on the big scale.

Chris: Well, listen to this. It's not -- I mean priority is one thing but it's like I almost don't even care if a button is high priority or low priority. What I actually care about is that the time between those two, between it being just a regular piece of HTML and it having an active, working JavaScript click handler on it is minimized. Whether that's high priority or low priority, I don't care. I just want it to never feel broken. It's either going to just behave like an HTML link or JavaScript is going to handle it and quickly, but nothing in between.

Dave: Mm-hmm.

Chris: I kind of like don't care about priority. I care about minimizing the gap. Anyway--

Dave: Yeah. Yeah, and I think, you know, there is -- I think at some point it's possible that it will go faster. Yeah, so they have one called "Is Input Pending." I'll just post some notes in the show link. They sort of like are proposing these things and they're kind of going through the implementation process. This is from last year and I think it's changed considerably, but I'll post a link to this "Is Input Pending" idea and then I think that has morphed into CPU scheduling.

10:45

Chris: That was the idea from Rory here, who was the original asker of the question. "Is there a way that you could run a little bit of JavaScript first," before your bigger bundle, I guess, is the implication here, "and kind of like remember all the events that happened on the page then wait for all their JavaScript to execute then execute those events after the JavaScript is loaded?" Kind of like, I don't like the gap. I want JavaScript to handle my events, but I don't want them to be forgotten about. This is kind of an interesting theory. I would think you're digging yourself into some technical debt hole if you went down that road and I would probably not recommend it, but it's not-not clever.

Dave: Yeah. Yeah. I just looked at the main thread scheduling on the wiki thing and there's a scheduler, so you create a scheduler, and so your tasks would be scheduled into a task. You basically create a task queue, if you've ever used Resque in Rails or something like that.

Chris: Right.

Dave: Or Sidekick or whatever. You basically have--

Chris: Been down all those roads.

Dave: Yeah. Right, but a little store and then the browser just kind of chucks through this stack list of tasks it needs to get through. Then there's scheduler.yield, scheduler.post-a-task and then is-input-pending on this thing. Apparently, that's something you can do or is coming. Again, I don't know the full status of this. You'd have to get kind of really deep into it. It looks like the last commit was April 24th, so it's under development or under sort of consideration.

Chris: I know IWS has queuing and scheduling and stuff now, too. I don't know if it's super new. I'm sure it's not, but it's new to me a little bit. Kind of like, chuck these tasks--

Of course, they do. They have everything.

Dave: Yeah. Yeah, well, we'll see.

12:43

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Honeybadger. That's honeybadger.io. Of course, the coolest CLD.

Well, it combines a couple of things. It's error monitoring. It's also uptime monitoring and cron monitoring and it's all together, so the error monitoring is a huge thing. It's one of those things where an app of any size, really, you've got to have some error monitoring. It's not an optional thing for your app. You need to know when your app is throwing errors, obviously, right?

It's back-end and front-end, so say you've got a Ruby app or something. You install it. Ruby throws an error. It's not just like being shown to users. It's being logged in the system with a stack trace and then you set up alerts so you can find out about it too.

You go to Honeybadger. You look. You see exactly what the error is and then you have the tools to fix the dang thing. That's vital. You don't want Twitter to be your first line of defense for an error, like, "Eh, I tried to change my password and got a 500." No! That's not good. You need to know about that right away and then it makes it easy to fix, too, because you see exactly what file, what line it happened on, and you fix the bug. That's backend and it supports a bunch of languages, of course.

But it's a bunch of JavaScript too, so it's your front-end too, because JavaScript can throw errors and it will catch those too and report those in the same system. It's the same for your cron jobs and your uptime too. Like if the whole site is down, you should know about that too. Of course, that's there too.

Honeybadger does it all, and it's a totally bootstrapped company from a small team. They're only beholden to you. You're their customers. You pay them, so it's the thing. There are not like teams and teams of shareholders to make happy here. It's nice. It's a small business kind of situation.

But don't take small for, like, that they're not best in class because they are. I use them. I think Honeybadger is sweet, so that's great.

They have a generous offer for you. Mention ShopTalk, the podcast, our podcast, right now, the one you're listening to, when you check out. You get 30% off for 6 months. If you came from us, you want to try out Honeybadger, get it a little cheaper for half a year. Pretty cool. Thanks, Honeybadger. Bye-bye.

[Banjo music stops]

15:07

Chris: We've got another question here. Chris Romero writes in, "I work for a digital agency that has been thinking more and more about how to integrate Web accessibility into our website builds. One possible "solution" to accessibility that has been brought up a few times by project stakeholders is using an accessibility widget. These widgets claim to comply with some level of WCAG standards without having to change your website code.

"Userway asks you to contact them to find out exactly or how exactly the widget is in compliance where accessiBe says their tool is in compliance with WCAG 2.1. I have very little experience with these widgets. Though we have already put one into production for a client, in my opinion, these tools add to the already confusing landscape of accessibility approaches out there also while potentially giving Web developers "permission" to simply ignore accessibility when they're building websites. A case could be made these solutions could be ideal for anyone that can't afford a complete refactor of their website but still want to provide some level of access to users with disabilities.

What are your thoughts on these tools? Should we be pushing back on them or another legitimate option? PS: Here are some URLs."

Again, from a liability standpoint, I would not really comment on these tools specifically or anything.

Chris: This is a bit of a new territory for me, but these just kind of crossed my desk just the other day. The bottom line is, I've never heard anything good ever about an accessibility widget. I've never heard anybody, like, put an accessibility widget on a page and then be like, [brush hands] "All done! We did it.!"

Dave: We solved blindness.

[Laughter]

Dave: No, I don't think it works that way.

Chris: JavaScript solves blindness. No, and it came across my desk because it was Adrian Roselli article and the title of the article is "AccessiBe," which is one of these ones from the question, "will get you sued."

Dave: Oof.

Chris: It's quite an article kind of talking about -- [Laughter] -- problems, as it were.

Dave: [Laughter] Well, Adrian is a hole poker. [Laughter] He finds the problems in stuff.

Chris: Right, so--

Dave: But--

Chris: Right, but also does kind of know what he's talking about, so it's tricky.

Dave: Definitely.

Chris: Yeah.

Dave: He knows what he's talking about. Very thorough, I would say, you know. I think you can read this and then this would be a very good thing to read.

Paciello Group is another accessibility consultancy.

Chris: Uh-huh.

Dave: They have one like these accessibility toolbars aren't the best. That was sort of their--

Chris: Right. Again, everything I ever read about them is bad.

Before we dunk on them anymore, what do they do? Is the idea that you put it on there and then don't some of the standards say, "Oh, you should have a widget to control the font size on the page," so you put the widget on the page and it offers a way to control the font size on the page? You feel like, "Ah, cool. Thanks."

Dave: Yeah. I mean if you think about it, there-- I'll say the positive. The positive is, just like in a video game where you can set the settings, like, "Oh, I want my subtitles really big," or "I want high contrast," or "I don't want this, you can turn things on and off in settings. Giving people options, that's something we learned with the ShopTalk site. Derek Featherstone was telling us we can give people options on maybe changing the heading, our weird ASCII heading, like if we could give people options, that's actually good for them because they can find.

They can tailor the legibility to their needs, basically. I am super into that. I think that's exactly right. Giving people options is usually a great accessibility solve.

On these tools, you can change font size. You can change colors. You can enforce--

Chris: Yeah, okay.

Dave: Saying minimum 7.1 and it'll just hammer the site or something or turn images off. Turn GIFs off, or something, like for motion sickness and stuff. Giving users control is a good thing. That said, it's not a really inclusive way to build because you built an inaccessible product and you're like, "Well, figure it out." You know?

Chris: Okay, so it's a sucky band-aid.

Dave: Non-sighted people.

Chris: It's like you broke your legs. Instead of fixing your legs, you're just like, "Well, I'll just walk with these two sticks then instead of legs."

Dave: Yeah. Yeah, I think it's just this very non-inclusive way. You're basically just band-aiding the whole thing and putting the accessibility on the user. You're saying, "Hey, you deal with it," not "I built an inaccessible website."

Also, if you did something inaccessible like a keyboard trap or a modal is wrong or something like that, that doesn't fix this. It doesn't fix the bad code you wrote. It just provides options to customize things for non-sighted users.

Chris: Okay, so--

Dave: Not even non-sighted because I don't even know what it could do for the accessibility object, you know, AOM. But it would be like for low vision users would probably be the most applicable group of people that this supports because people who need higher contrast or larger text or different colors and stuff like that. It really only supports one fraction of people that kind of have a disability.

That said, I think it's better than nothing. I mean if your company is just like, "Oh, we are doing nothing for accessibility over the next year," again, I'm not a lawyer. I think it sounds like Adrian really thinks it will get you sued, so you should be careful. You should definitely read this, but I don't think it solves something, or I think it's better than nothing. If you have a big legacy product, maybe this helps you clear up some of your WCAG violations. But again, I don't know. I don't know that it's just instant free no -- you know. I don't know.

Chris: It doesn't solve all your problems.

Dave: When have you ever--?

Chris: We can also say the right answer is to actually fix your accessibility problems. Okay? Great. But you could see how somebody is like, well, that's hard, especially without understanding what any particular code base or organization is like. If this is a band-aid for something that is a really difficult situation, maybe. Yeah, it sounds like even the tool itself is inaccessible and stuff like that. There are some pretty deep problems here and it wants to be a band-aid. Band-aids can be okay, but this particular band-aid isn't okay. Although, don't quote me on that. This is not my research I'm looking at here, but I am not compelled by them.

There is no flipping way I would use one of these things, almost like at a gut level, like… No! [Laughter] I can't even describe exactly why, but I'm like, "Whoa! Some junky widget on the page?" I hate widgets anyway let alone one that I have no control over that's influencing the site. Maybe that's shortsighted because this is helping people, not me, but I have kind of a visceral reaction to these things.

Dave: Yeah. I just can't think of any time where it's like, "Oh, just install this toolbar and all your problems are solved." I think it speaks to the larger accessibility problem where 98% of websites are inaccessible or whatever. It's like we just are looking for quick fixes. We don't understand the underlying accessibility problems.

If you're like, "Oh, if I install this, does it fix it?" It's like, "Well, do you know what your problems are?" You know? If you know what your problems are then it might. But you've got to know what your problems are. Anyway--

Chris: It looks like a lot of other people are angry about them too and, apparently, they use some kind of fear-based tactics to get you to install it, which I also hate. Like, "You should be scared of the accessibility problems on your website and you need us," because it's like a malware thing. "We have scanned your hard drive. There are problems. Download this tool." That's the vibe. Don't like it.

Dave: Oh, I mean, heck, man. Not to be a, whatever, here's my bad faith take. I mean if I was one of these companies, I would also employ a lawyer to go just robo-sue people, like just run an automated test.

Chris: I got one the other day. I'm sure you saw. I got a letter in the mail in a very -- they spent like $5 to send me this thing that made it look really official, so it was like hand-delivered to me with a lawyer's autograph on it saying that, "We're not suing you yet, but we're working on it," kind of thing. [Laughter] If you read it wrong, you might assume that you are getting sued. It was like, "Please get in touch with us because we're willing to settle out of court," kind of thing. it was such BS. It was the most BS thing I've ever seen.

Dave: Yeah! So BS. It's like there are a lot of malpractice kind of happening in this area, but it's like you get the sales pitch on this and people are like, "Nah, no thank you." But then a week later, oh, surprise. A little lawyer shows up. Now they might rethink that.

Oops, the price is higher. Anyway. I'm being cynical here but this is like -- there's blood in the water and the sharks are here, so you have to be careful. Both people trying to sell you snake oil to solve your accessibility problems, but then people trying to sue you and take your money.

Chris: Yeah.

Dave: There is legal precedent like the Dominos case was very significant recently. It's something you have to do, so if you have customers and things like that. Does CSS-Tricks have a big surface area? Apparently, it does or something. I don't know. But you have to be careful. I think understanding the underlying problems is probably more important than installing a toolbar that promises to fix it all.

26:31

Chris: Yeah, I like that accessibility people pounce on this stuff like, "Don't make our trade look bad." Like when a crappy lawyer does something crappy and good lawyers pounce on them kind of thing. I kind of like that.

It's like you almost wish the React community did it more, like when there's a bad actor in that particular sub-community. It's like you wish they would get piled on a little harder and I think that's been getting better, you know. People should be protective of their thing, you know, when there's bad actors.

Dave: Yeah, if there are bad actors, call them out. But then also just try to -- I don't know. If you're going to do my job or whatever, you need to do it in the best way possible and these are all the considerations I make. If I've learned anything about accessibility, I've been working with an accessibility team for a large company for the last year. There's just a lot of nuance in accessibility. It's unavoidable and you kind of just have to know enough, you know. Like an accordion. In the main div, that needs headings because people navigate by that. If it's a sidebar accordion, it doesn't need headings. Why would it need headings?

There are all these little things, just little nuances that you don't know unless you work with somebody. That's kind of like Derek's mantra is, "Build inclusively," and he ran -- he's going to talk about it, I think, at Event Apart. He ran our site, ShopTalkShow.com, through accessibility testing and got feedback from people. They were like, "Oh, this was confusing," or "That was confusing," or "This helped."

Chris: Right.

Dave: It even helped us, too. Do you use transcripts or do you listen to podcasts that ever, you know, and people read transcripts? Most people were like, "No," because they never exist. It's helpful.

Chris: Yeah. There were some interesting things in one, just because you went down that road. We have a lot of work to do here, by the way. Not necessarily on accessibility stuff, although Derek is on it, so if he gives us anything, we just do it.

One of them was kind of about using some kind of fixed positioning on the player, which we ended up using Sticky on, and it might be a little aggressive now because the player is so beefy on the site that it takes up a lot of room.

Dave: Yeah. Yeah.

Chris: But anyway, it's Sticky. That way, if you are a transcript user, you can listen to the show and use the transcript. You can still pause the show. You still have access to the player while you're reading the transcript. That was like, they wanted that.

Then they wanted to be able to jump to different parts in the show, so there's kind of like a drop-down for that. You can open that up and then click to get there. Now, that's been there for a long time because that's Dave's library. What did you call that thing? The magic linker machine or whatever?

Dave: Time jump.

Chris: Time jump.

Dave: Time jump.

Chris: Yeah, that's cool, so we've had that forever but it's wired into the site in good ways. But then some additional feedback we had is let's say you're down the transcript a ways and you're reading with your eyes, like, "Oh, this is the part that interests me. I want to jump to there." Well, how do you do that? We might not have a timestamp for it in our regular time stamps.

I was like, well, I don't know. We don't have the data. We can't solve an accessibility problem if we don't have the data. So, I just emailed our transcript person, Tina Pham, and we're like, "Can you do time stamps, like periodically within the thing in this thing?" She's like, "Okay."

Dave: [Laughter]

Chris: That's what it took to solve that accessibility problem was one email, like not a big deal at all. Now, she charges by the hour. It's super affordable, I think. Thank you, Tina. You know, I'm sure the price went up 3% or something because it takes her an extra second to put that link in there or something. It's not nothing but, in the grand scheme of things, trivial.

I have another accessibility thing to run past you today. I just think this is -- I don't know what to think of it, but it's kind of like buckets of how you can help accessibility. Think of just one thing, just to scope it. Prefers reduced motion. You're familiar?

30:49

Dave: Yes, so that's the API where you can -- the user would set something like, "Oh, I get motion sickness. I prefer reduced motion." Then in my code, I can basically turn off an animation if needed.

Chris: Or something. Adjust it, yeah.

Dave: Yeah.

Chris: Yeah.

Dave: Or a transition, a really gnarly transition or something.

Chris: Right. Yeah. Yeah. I think a lot of people turn it off, but I think there's some nuance there. As long as you really reduce it, you don't have to give up on all animation ever. You just need to not be so crazy about it. Yeah, I'm sure on Windows there's some checkbox somewhere. I know on Mac it's in the accessibility settings. You can check a thing that does that. Now, the OS itself will do less animation. That's great.

Prefers reduced motion on the Web is a media query for doing exactly what you said to do, not to reexplain it. I just mean that the media query is the important thing, right? Now you can write just like you can write a min-width, max-width, whatever kind of media query. You can write specific CSS that's for prefers reduced motion.

Okay. We have it. We have the tool. Cool, right? Here's the different buckets that I think are interesting. You could implement it on your site and you could use it. That fixes it for people that really prefer this. I'm sure there are plenty. You have solved that particular kind of problem, like showing less animation on your site for every single user that has that enabled, which is kind of cool. It's kind of like every user one site.

Now, if you tackled that problem from another way, you could, for example, Dave Rupert, write a browser plugin, which will now run on Safari too, interestingly, because it's the same format for all the major browsers now. Did you know that? It's kind of cool.

Dave: Oh!

Chris: You write one plugin and it'll run in Chrome, Firefox, and Safari, which is sweet.

Dave: I have, yeah, and I'm really hopeful that Coil goes to my phone.

Chris: Oh, that'd be nice. Yeah.

Dave: Fingers crossed.

Chris: I rolled out a test on that on CodePen, by the way, just to see if that scale would be any different. Anyway, okay, it's an extension.

Dave: Curious. Curious.

Chris: You wrote this extension and what it does is it takes a heavy hand. Rather than doing a nuanced kind of, you know, I'm going to chill out these animations, you just wrote a media -- it like injected CSS on the page, this browser extension does, that says it prefers reduced -- motion is reduced. Then you do star selector transition zero-second important, animation non-important, whatever. You wipe out all animations on the page.

What you're doing then is, for one user, you're solving all websites. Isn't that interesting? If you're trying to solve this problem, there are two different angles you can scope it at. It's like solve it for all users on one website or one user for all websites. It's kind of funny.

Then if you're a browser vendor, Chrome could do this if they wanted to, or Safari, Firefox, or anybody else. They could kind of force it. They could say, "Well, if people have this on, I'm not going to let you do certain types of animations." I don't think they ever would do that. I think that's too heavy-handed for a browser to do.

Dave: Mm-hmm.

Chris: But they could if they wanted to. It's in the bucket of something that they could do and that would solve it on both sides. It would solve it for all websites for all users. It's kind of interesting, the different tools we have and how that kind of appeals to different people, you know.

Dave: Yeah. I've heard a little bit of pushback, actually, on this. I think somebody pulled up Cassie Evans's new site, which is awesome and has a lot of motion.

Chris: Mm-hmm. They're like, "I don't see the animations." I think she was like, "Well, do you have prefers reduced animation on?" You know? [Laughter]

Chris: Mm-hmm.

Dave: They're like, "Yeah," and so there's a little disconnect because they were maybe trying to solve their max dock, like when the doc goes [zipping and humming]--

Chris: Yeah.

Dave: --or whatever, and it's really kind of intense and it's kind of nauseating even to me. I'm pretty fine on the vestibular front. I think some people were like, "Oh, I'm not seeing it," but it's probably because you reduced motion on your OS.

Again, I sort of wish browsers could -- I feel like this with dark mode, too. I wish there was an OS setting, but I wish there was also a browser level setting for, "Oh, actually show me the light mode," or "Even if my OS in dark mode, show me the light mode." I think Edge does that or Windows has that. It's like go dark theme but light content or whatever, light applications or something.

Chris: You know what this reminds me of is role-based permissions and how a role can -- you can set up a role and the role has these X things in it and the role could take websites or it could take logged in users or it could take anything. Then the role does different things.

Right now, we don't have that. We just have this very global setting, but another approach to this that's kind of time-tested is role-based permissions. The permission could be, like, "Well, I like dark mode and prefers reduced motion." Then it could drag website URLs into that role, and it would be specific to those websites. That'd be kind of cool. Or I want to apply it globally if I want to.

Dave: Even if there's granularity or something, like some motion or reduced or off or something. Reduced or off would be kind of cool, you know, those two levels. On the off setting, browsers could just nuke it entirely. On the reduced setting, I could just go do my job a little better or have some author decisions or something. I don't know. But then again, people might just use a plugin, like user style thing, and just nuke it entirely, you know.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Advanced Custom Fields, ACF. That's advancedcustomfields.com, a plugin for WordPress that, if you didn't know, is one of the nicest ones out there.

It really makes WordPress into a proper CMS in that you can say, "Hey, I need this group of fields. I'm building a real estate site. I need to have houses and houses have a price, square footage, number of bathrooms, description, which agent is representing it, and yadda-yadda-yadda. You can flesh that out really quickly and attach it to a post or a custom post type. Boom. You're really cooking with gas. Now you're making a WordPress site with just the data that you need.

It doesn't just kind of work. It really works wonderfully. They've been around a long time perfecting how well this works.

Now, the Gutenberg editor … the block editor in WordPress, they invented a way to make building blocks for the block editor tremendously good. You do it all in PHP. It's just like regular WordPress development. You declare a block. There's this whole function for it like what's the name, what its ID, what kind of icon does it have, what keywords does it have, because that makes it easy to pop up in the block editor. Wonderful.

You point it to another PHP file that says, "This is where I'm going to render it," so it could be div ID my house or a house, whatever. You output all the stuff you want in there.

Now, you could do nothing. I mean this block could be static content if you wanted it to be. It doesn't even need to pull in ACF fields. It's just a way to build a block. It could be just static stuff or it could have its own calls in there that pull data from wherever and display it. It's just a way to build a block, although, I'd say, in general, it works really nicely with custom fields. You bundle that all up together.

Let me tell you a really quick story because I think this is a cool development story. I was whining the other day, "Oh, WordPress doesn't have a good detail summary block." Now you know what those are in HTML, right? Details wraps this chunk and then there's a summary tag inside it. The summary tag has a triangle next to it. You can open it and close it. It's like toggleable content. You need no CSS or JavaScript to make this work. It's a tremendously nice feature of HTML.

I like to use them in blog posts sometimes, you know, be able to toggle a section collapse that might just be extra content that you don't always need to be looking at or has a spoiler in it or something. WordPress, the block editor, doesn't have a detailed summary element, but I wanted to build one. You can, in the block editor, make an HTML block and then just manually write HTML, like detail summary, but that sucks because then you can't use other blocks inside of it.

Now, there are a couple of takes on the WordPress marketplace that have a detail summary block and it's okay, but it's kind of like, what's the summary? What text do you want to put inside? That's it. You can't put arbitrary blocks inside.

And in the old days of ACF blocks, you couldn't either. Not really. You couldn't make an ACF block and then just say, "You know what should go inside this? Just arbitrary other blocks: list blocks, black quote blocks, images, columns, and literally any other block." This beta release and, maybe by the time you're listening to this, it won't even be beta anymore, but it works great. It's in like beta 3 now.

I just was playing with it yesterday. You can just put in your template, where you're building the block, one line of code--inner blocks--and make it look like JSX with a capital I, capital B with the closing, self-closing slash. Then it's just saying, "In this block, accept any other block inside of it." It's just incredible, so you can have this wrapper block and then just use the block editor and just be dragging and dropping blocks inside of it like any other block. It really feels magical and it totally solved my detail summary problem because I made my own detail summary block that has inner blocks inside of it, so I can do whatever I want now, and it feels very satisfying. I wrote it in very few lines of code.

I know this was a long sponsorship spot, but it's really cool. High five, ACF. You do great work. You make WordPress better and we appreciate it. Thank you.

[Banjo music stops]

Chris: Very, very interesting. Gosh, we end up talking about so much stuff, I barely even remember we started talking about widgets and stuff, but we drove that into the ground. Let's do this one from Derek Austin, which is -- [Laughter] -- this is fascinating.

"I'm one year into a career change from physical therapy to Web development and I've been blogging about JavaScript on Medium.com," so one year in. "My question is, what do you think about Medium as a way of monetizing your blog?" He says, "So far, I've made about $6,000 and received one million views from the 100 articles I've posted there over the last year."

That seems to be the "worth it" type of money that Dave wants from his blog. Keep … Derek Austin, so derek_develops is his Medium username. He's written 100 blog posts and made 6 Gs on Medium. Wow! In a year!

Dave: I'm just going to go ahead and say, you're doing way better than me.

Chris: [Laughter]

Dave: I make $20 a month and you're pulling $60 an article. Keep doing what you're doing. That's actually pretty incredible reach there.

I think I'm in the one million page view range, but I have different analytics that tell me different things. But I think you're doing pretty good there, so I wouldn't switch. I mean I don't know. I'm always a big fine of the, like, own your own content, so I think having it outside of Medium is good, but it sounds like Medium is also, whatever, at least paying you.

Chris: Does everyone get paid on Medium or do you have to turn it on? The criticism you see is you write on Medium and you don't even know if it's going to get paywalled or not. It's like, surprise, it's paywalled now.

Dave: Yeah.

Chris: Which that seems weird. Can you turn on the paywall all the time if you want? I mean I guess we're doing this fricken' podcast. We could have at least researched it. Sorry, listeners. I'm not in the Medium market. I've already got a blog. I'm very happy there. I make a bit more than that blogging. We've in different categories a little bit, so I'm not looking to start porting my stuff to Medium, necessarily, but I've never heard the numbers before. This is my first time hearing somebody that's doing this well.

The other stories I hear is, like, free code camp piecing out of Medium. There was a time for a little while where everybody was piecing out.

Dave: I think this is good. This isn't like "quit your job and retire" money quite yet, $6,000 over 100 articles. Let's say you're prolific and can do one article a week or two articles a week. I don't know.

Chris: It would be three for him.

Dave: What would be a lot of articles? Three, right? Three articles a week.

Chris: For $500 a month, essentially, which is really not bad. Plus, you do kind of own it, you know. You wrote it.

Dave: Yeah, it's yours. Yeah. I think that's pretty good. Again, you're getting $60 an article, on average. That's pretty good because that's your money. You didn't have to take a cut.

Chris: No, nor did you deal with the advertisers. That money just arrived, which don't discount that. Dealing with all the ads yourself is a pain.

Dave: It's hard.

Chris: Yeah.

Dave: I think even with podcasting, there's always this dream I'll do a podcast and money will just show up. Not always.

Chris: But you're not gunning for this. I'm looking at Derek's blog right now. It's like how to add footnotes on Medium. What is JSON used for in JavaScript programming? How to check if jQuery is loaded on the page. Two Gmail secrets everyone should know. How to apply CSS styles to page elements using JavaScript.

This is the path I'd like to tread down. I've been trying to get us to do more of this type of stuff, like just answer a question really clearly because, for me, Google has been great for us. We can use our good SEO and the more how-to articles we publish like this, the better that's going to get. I think that's smart for technical writing, in general.

I think Derek kind of intuitively understood that and just rolls with it and just answers really clear questions that probably he's figuring out and then is like, "I'm just going to publish an article that very clearly answers that question." Of course, that's going to do well.

I'd say, if that was your goal, Dave, if you were like, "I am going to make money blogging and this is my singular prize on Earth," you could absolutely do that.

Dave: I could do that. What's important here, I'm looking at the date stamps, like Derek is showing up to work every day to blog. He's not just -- this isn't like a passive -- every day there's a blog post. A) You've got good content scheduling and B) you're just showing up. I think that's part of it too. Yeah, I think I could. I could maybe do something like that. I don't know.

Chris: Well, do you want to? That's the thing. I think a lot of people want this because it's cool because it's passive income. It's a way that you can just kind of turn some words into some money in kind of a long-lasting way. I'm about to write my thirteenth anniversary of CSS-Tricks post and it took five, at least, to make it to probably Derek's level here, and then it's gone up. But it's no joke, the amount of work. You're not going to step into it. I think it's very rare to have Derek's level of success here in year one.

Dave: Yeah.

Chris: But he's proven it can be done. But I do think you need to follow this general formula. I think you need to make it easier on yourself. You've got to show up every day, and you've got to write articles that are just easy to digest, how-to, answer a question. That's going to get you the claps you need here.

Dave: He's got a lot of two-minute reads, eight-minute read, ten-minute read, you know, three-minute, five-minute. Derek, you're doing great. This is a good pocket to be in.

Chris: Oh, yeah. Killing it.

Dave: I think, for my blogging, my blogging is all just get the thought vomit out of the brain-machine because my brain is just consumed with, like, I think last week we spent 20 minutes talking about how to put an image on a webpage or an optimized image. That's what my brain gets consumed with, and so even this podcast, too, some of that, just getting these thoughts out and in a place where now I don't have to think about it anymore. I think my blog is a good place for that, too. It's just like, "Okay, now these thoughts are documented. I can come back to them later."

I think I could take it more seriously. I don't know if blogging -- I like blogging, but I think video is very interesting, Twitch, live streaming is very interesting to me, but … that.

Chris: Yeah. There's irony, right? You're like deep thoughts. These important, philosophical thoughts, to me, are the best blog posts and they'll never make any money. Nobody is making money writing essays on that kind of thing. You've got to monetize it in a different way. If you're going to do that, call it a magazine. Sell the issue. Sell it to the audience of people that want that kind of thing directly. But it's not going to drive the page views like SEO content will to make advertising your vehicle.

Dave: Yeah.

Chris: You can't write the -- I'm not going to say it again. I was just going to say the same thing over again.

Dave: I thought about printing a zine, like a paper, photocopier paper kind of zine or something, collecting articles and stuff like that. I think that would be kind of fun. Robin Rendle has kind of talked about doing that on an ebook front.

Chris: Robin is a great blogger, but it's all thoughts. It's all, "Here's me." He's not going to make money putting Google AdSense on there. It's going to be minimal at most.

Dave: Yeah. Right.

Chris: Yeah.

Dave: That's why news is dead.

[Laughter]

Dave: And that's news is dead, tonight at 10:00. Oh, boy, well--

Chris: Even if you're going to do clickbait, you've got to do a lot of it.

Dave: You do. You do. Well, I think my go-to here is Smashing Magazine. Love Vitaly. But for the first five years of Smashing, it was top ten jQuery plugins that'll rock your socks and top ten new tools plugins that will rock your socks and top ten prototype plugins. It was very formulaic and to get to the top of dig.com or whatever. It was very clickbait-y or just even this digestible stuff. Then I like how they've made a pivot to kind of more complete pieces, big pieces, thorough research, and all that. Not saying it can't be both. I think you can build, grow, and get this $6,000 with the 100 blog posts by, again, the saccharine or even just the simple stuff. I think you can do it with how to copy objects and arrays in JavaScript. That's a really helpful post. I think you can get big and monetize that way but, yeah, then I think eventually a lot of people try to go to a bigger outlet or, whatever, bigger thinking.

Chris: Yeah. Yeah. I think a desire for control for these type of things is desirable too. At some point you're like, I wish I could just do whatever I want here and you can't.

Dave: Yeah. Yeah.

Chris: You can if you have your own website.

Dave: Well, yeah, because you're just stuck, right? That's the stuff that sells, so you can get stuck in that.

Chris: Yeah, I mean even like layout and I wish I could--I don't know--sell a T-shirt and have a nice checkout flow right on the site. Well, you can't on Medium. Too bad. You've got to--I don't know--pick somewhere in the article and hand inject some code that says, "We sell T-shirts now," and it's not a programmatic widget that you can change. You just hand-wrote it into the content of the article. I think that type of stuff would wear on me after a while like, "Meh, I need a little more programmatic control here."

Dave: Yeah, that's why. I mean not that I super leverage that, but that's why I like my own site. I also like my own site for a lot of reasons.

Chris: A million reasons. That would be a good show.

Dave: I like to mess up on my own site before I mess up on a client site. That's a big one for me.

Chris: Yeah. There you go.

Dave: Well, cool. I officially have a meeting, so I'm probably going to have to drop off.

[Laughter]

Chris: All good, Dave. I have a couple meetings today, too. It's just been back-to-back recently. It's been good, though.

Dave: It's the time, so we should wrap it up here. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. Head over to ShopTalkShow.com/jobs to get a brand new one because people want to hire people like you. Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.