CodePen Blog
Chris’ Corner: A11Y

I’ve got a couple of accessibility related articles I thought I’d share this week. I’ve specifically picked them out as examples of well-done accessibility writing. For each, I’ve plucked out a bit I found particularly interesting. But you, you should read the whole thing.

* Demystifying WCAG 2.2 by Nathan Schmidt. WCAG 2.2 was released late 2023 (and so was this article), but I’m pretty sure 2.2 is the latest stable recommendation, with 3 still being experimental. WCAG is a “technical standard”, like other web specs, so it’s not written for regular website developers like me or you. Nathan’s article, however, is and it covers what’s new about 2.2. I learned that those options on forms like “Shipping address same as billing address? that prevent you from having to enter the same information twice are actually required.
* Super short note on CSS text by Steve Faulkner. A good reminder that not all screen readers behave the same. Like with ? with span::before { content: "?"; } “JAWS announces “question mark, question mark” NVDA does not announce anything.”
* Screenreader only by Donnie D’Amato. Donnie doesn’t love utility classes in CSS. Even setups that don’t use them generally still typically have a .screenreader-only or .visually-hidden. But what if that was a component, what would the semantics of it be?
* Content hiding techniques and their accessibility implications by Sara Soueidan. Speaking of those screenreader-only still utilities, we specifically use those because other methods of hiding have side effects we don’t want. For example, a bit of text for screenreaders-only (and thus visually hidden) can’t use display: none; or it will be hidden from the accessibility tree as well, making it useless. We can’t use visibility: hidden; either for the same reason and it would still take up space in the flow. There are a lot more hiding techniques as well, and Sara compares, as the title says, their accessibility implications.
* Data Table Accessibility in 2024 by Zell Liew. Zell makes a table out of display: grid; and subgrid… and the results were that “Table semantics was not stripped out by screen readers in most browsers. They were able to announce table, rows, and columns accurately.” (with the very notable exception of Voiceover + Safari.
* contrast-color() is a good thing, but also solving the problem at the wrong layer by Eric Bailey. Eric wrote this in 2024 but it’s especially notable now as the CSS function just became widely available last month. Eric wonders, among other things “Why does all this have to be the website or webapp author’s responsibility?” Would the web be better if browsers enforced this automatically? (Probably.)

CodePen Blog
Chris’ Corner: Design

I’ve been doing computers for a good minute, but the Scroll Lock key still predates me. There may have been a day when I could have explained what it does, but that knowledge had evaporated until I read Marcin Wichary’s Lock Scroll With a Vengeance. It’s fascinating that the technology that deprecates the Scroll Lock key is… the mouse (and scrollbars and trackpads). Stuff that’s been around. I’m very sure Excel nerds still use love it.

If I must fingersplain a fairly visual concept (I must): scroll Lock, when enabled, keeps the visually selected thing right where it was as you scroll, rather than requiring the selected thing to be butted up against an edge to trigger scrolling movement as it pushes beyond that edge. I think that was a perfect sentence, but your call. Go look at Marcin’s post to see how this effect has actually made its way into modern interfaces, without the key’s opt-in. My take is that if you’re going to do this, the selected item should be very centered so you can see other items in all directions around it. The examples from HBO Max and YouTube just forced the locked item to the other edge. I’d bet a donut it’s so users “see more sooner”.

Welp, we’re getting a smidge reflective about design, here’s a zinger from Barry Prendergast: The worst designer I’ve ever worked with was also the most productive. It’s exactly what you think it is:

This ambitious young designer pumped out more screens in a day than more-experienced designers would in a week. Leadership adored them. They saw the speed, the volume, the ‘beast mode’ energy — and mistook it for value creation.

It didn’t go well. The lesson?

Good designers slow down when it matters. To clarify the problem. To align with their team. To create outcomes that matter.

I can feel how really talented designers at big orgs are, especially feeling the AI anxiety. Whippin’ out screens ain’t it, which is what AI (and, apparently, particularly energetic and misguided junior devs) are good at. Real design has always been a much more nuanced affair. Jem Gold hits it nicely in Design Is How It Tastes with a banger subhead:

If our design specs only tell models what the interface is made of, they have already forgotten what the interface is for

I admit I’m very impressed at what coding agents can do these days, but I remain skeptical that AI can really understand the human experience, a prereq for great design. At the moment, AI is headed for the more rote instructions-following output:

A few months ago, Google Labs released DESIGN.md. The idea is sound: codify your design ethos in a single markdown file so that coding agents can implement it consistently. Write it once, ship it everywhere. Portability matters because interfaces are increasingly built by or with agents.

But read a typical DESIGN.md and you will find language like this:

Use 8px radii. Use a neutral palette with a pink accent. Buttons should have primary and secondary states. Cards should have subtle borders.

Useful, but thin. It describes the produced object. It does not preserve the intended encounter.

I used the word “great” design above. A worthy distinction. Certainly AI can poop out generic but decent design. I see live design work powering successful companies regularly that would probably benefit from letting an AI loose on their pages. Bringing up the average bar is probably a good thing for the web. But great design remains a human endeavor. CodePen Alum Jake Albaugh opens his Design is the work article with:

We’re in a moment where it has never been cheaper or faster to build something convincing.

There is all this stuff we know that is absolutely vital to what we build. Jake lists a small handful of that stuff:

AI doesn’t know your constraints. It doesn’t know your strategy. It doesn’t know what moment in the market you’re in, what your team is trying to prove, or what your customers [...]

CodePen Blog
428: Billing

Rachel and Chris on the show this week to discuss a series of big changes over the last, say, six months or so with our billing system. We’ve essentially re-written this thing several times, and obviously this is the best time. Having three plans, two payment providers, teams, and fifteen years of history is a lot to manage.

An important aspect of the journey was getting the billing information into a single table in our database, and relying more on dynamic calls out to the payment providers when needed rather than trying to keep too much data in sync.

Of course we wanted to clean up the codebase and get payment APIs ported over to our latest system, but the biggest need this was all satisfying was UX. We wanted a proper pricing page, better pages for people to manage their billing, and really easy upgrade modals inside our 2.0 editor.

The good news is, it all worked.

Time Jumps
* 00:00:20 Who’s excited to hear about billing?
* 00:01:24 Being able to upgrade in the new editor
* 00:02:28 Keeping data in sync with payment processors
* 00:08:50 How we plan to use new APIs in payments
* 00:11:47 Changes we’ve made to our payment modals
* 00:18:18 Keeping support for Paypal
* 00:22:17 CodePen’s pricing page
* 00:29:18 Keeping things simple for upgrade suggestions
* 00:39:20 What’s left for pricing and teams pages

Image generator studio

Output of this code

CodePen Blog
Chris’ Corner: The Edge, Man

Ryan Mulligan’s article Transition to the Other Wide with Container Query Units is some solid CSS catnip for me. Just this base thought is fun to think about: how do you move an element from flush-left to flush-right when the size of the container and element are both unknown (which is typical). https://blog.codepen.io/wp-content/uploads/2026/06/edge-to-edge-1024x292.png It’s like you want to have left: 0; as a starting state and right: 0; as an ending state, but as those a different properties, you cannot animate between them. You could have left: 0; as the starting state (or nothing, as that’s default) and left: 100%; as the ending state, but that’s not “flush right”, it’s “align the left edge of the element with the right edge of the container”, which isn’t quite right. A good fix for this is to make left: 100%; translate: -100% 0; the ending state! Kind of a classic. The -100% of the translate refers to the width of the element, so it sucks it back to the left “one element’s worth”, which ends up with flush-right alignment. Cool.

That solution is maybe a little funky though. Personally, I don’t love how there is a use of two “100%” values that just-so-happen to mean different things, and they are sitting right next to each other. Ryan presents a bit of a better solution in making the container a literal container with container-type: inline-size; so you can use container units inside, then moving the element with translate: calc(100cqi - 100%);. The different units there, and the single declaration, do feel better to me.

That’s kinda where Ryan stopped, but he did mention View Transitions at the top of the post, and that’s interesting to me because of how I opened the 2nd paragraph above. View Transitions don’t really care how you move something from one state to another, it just looks at the before and after states and tweens. So we really could do left: 0; and right: 0; as the two states and let the movement happen between them. But now we’re talking JavaScript of course, so we’ve got to use JavaScript events. Tradeoffs all around!

While I was playing with it I put all three ideas into a Pen, because, uhh, duh.

CodePen Embed Fallback

While that kinda stuff is a little cutting edge, it’s not nearly as much as the rest of these HOT LINKS I’ve saved for you.

There is a thing called Scroll-Triggered Animations now. Scroll-Driven Animations are already very cool, but those attach a timeline to scrolling position in one way or another. With the “Triggered” varietal, the animation can keep a duration-based timeline, but just be kicked off when a particularly element becomes visible (which itself has lots of control points). I like looking at really dumb easy implementations to get it, so I made my own “Wave at the Bottom” demo. Bramus’ Fly-In Text should make the point strongly as well.

CodePen Embed Fallback CSS Grid Lanes “are here” as they say. They work in Safari and are flagged in both Safari and Firefox. This is the thing that’s basically “masonry” layout. Nice simple (yet powerful) final API. And you can use it pretty easily now, because the fallback is still just a grid layout. I used it on a redesign of my personal site.
https://blog.codepen.io/wp-content/uploads/2026/06/Screenshot-2026-06-11-at-1.41.02-PM-1024x627.png Safari with Grid Lanes on the Left, Firefox without on the right. Whatever.
Perhaps you’ve heard of customizeable menus now. They are absolutely awesome. You have full CSS control. And for the most part, all of you fine sensible people will do sensible and tasteful things with it. But as it’s an interactive element, it absolutely begs to be messed with, so we’re seeing wild experiments like Chris Bolson doing a 3D globe selector fo[...]

r countries and Temani Afif turning a select into a shooting range.

But there is more newness afoot here. Brecht De Ruyte explains we’ve got now too. The UX of this used to uhhhh kinda suck turds, but Brecht’s demos are proving that they can be pretty great now.

CodePen Embed Fallback

Plus! Safari now supports customizable selects too, so hooray for that.

CSS having @function now is pretty cutting edge. It unlocks some new syntax and ideas, with has its ups and downs as far as DX. But people are really putting it to work in cool ways.

Sindre Sorhus has “a collection of useful CSS custom functions” (see them directly here). Mostly one liners! Makes me think how we might need to start tree shaking CSS.

CodePen Blog
429: Why CodePen Rebuilt Its Realtime Service

We’ve had realtime features on CodePen for ages. Back when it was pretty damn hard. Our Collab Mode is an obvious one, where users can code together. (This “just works” in the 2.0 editor, it’s not called anything special.) That and Professor Mode used to have realtime chat (until we pulled it because very few people used it). We went through iterations of this including our own implementations and using services like PubNub.

Code collaboration in realtime is particularly difficult. We used FirePad/FireBase for a while for this, and honestly that was a nice abstraction. Increasing the difficulty though, we need to layer on additional needs like syncing settings, presence, and just arbitrary message delivery (e.g. “a new build is ready!”). We used Ably for much of this for quite a while.

These days, our whole realtime system integrates with our caching layer, goes over the network using standard web sockets to our beefy Go servers, and is integrated with CRDTs/Y.js to keep everybody looking at the same thing. Plenty of open source software at work, but no more third-party services. This means lower operating costs and a simpler architecture. The cost is that problems are, well, our problems.

Time Jumps
* 00:00:07 Why did CodePen rebuild it’s realtime service?
* 00:03:11 People take realtime for granted in 2026
* 00:04:56 What tech did we use in the past to do realtime?
* 00:13:01 What did Ably used to provide?
* 00:16:36 What we ended up doing
* 00:26:27 What are the issues with doing realtime yourself?
* 00:32:59 What would we do differently?

Color Converter · HEX · RGB · HSL · CMYK