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

CodePen Blog
Chris’ Corner: Makin’ Stuff

The most fun websites to build are websites that interact with outside sources. A user is an outside source! I’m obviously a bit partial to a website that asks a user to build stuff. That’s fun. But any outside source can be fun. Accepting uploads and doing something weird or useful with the data. Or using a third-party API for interesting data.

There is something magically fun about a weather app, for instance. You’re designing the site, but it’s designed around data you don’t control. Your job is to present the weather in a pleasing and useful way. That’s difficult to do even when you’re essentially copying patterns that already exist for it, and extra difficult to do something novel that could attract actual customers.

I’ve seen a college program that has students literally build a weather app. That’s a great project if you ask me. It involves an outside source of data, so you learn how to do that and make it efficient and resilient and respect bandwidth and limits and all that. The students also learn that websites are both front-end and back-end, and neither can fully compensate for weaknesses in the other.

A weather site is a pretty saturated space. But I believe in you, you can do it! There are other opportunities out there, though. Perhaps after you’ve got your feet wet with interacting with outside sources, something else will click for you that feels more personal.

I was thinking about this after reading Terence Eden’s Are there any open APIs left?. It was very interesting to me as I was vaguely under the impression that most of the really interesting cool open APIs didn’t really exist anymore. And, to be clear, “API” meaning general data access from some third-party source. A classic is that GitHub offers REST and GraphQL APIs for your use. Could you build something interesting with access to GitHub data? Or, perhaps a better question is could you build something interesting with access to GitHub data and whatever other outside source you can think of. Terence’s blog post lists some APIs still going strong.

Speaking of outside sources, let me leave you with a somewhat random collection of links to tools and ideas that maybe-just-maybe could be alchemized into an interesting website.

* Defuddle — “Get the main content of any page as Markdown.”
* Curate your own newspaper with RSS by Molly White
* Introducing the <geolocationHTML element on the Chrome blog
* A Gentle Introduction to CRDTs — “CRDTs are needed in situations where you want multiple processes to modify the same state without coordinating their writes to that state.”

🤔