Smartphone GPS works offline to determine your location.

CodePen Blog
Chris’ Corner: Finding Type

Finding the typeface you need is a whole thing. You’ll know it when you see it is one approach. Look at a lot of choices. Make sure to save ones that you think are really nice, even if they aren’t the winner this time. On my local machine, I use an app called Typeface. I try to tag stuff in categories that make sense to me. I have a good amount of nice stuff in there, but still, when looking for a web project, it’s limiting, because I don’t have local versions of all the typefaces that would be good candidates for a web project. All of Google Fonts, for instance, I have no interest in keeping local copies of. And it’s extremely cost-prohibitive to buy every great font I see available for purchase.

I find it interesting to look at ways to explore typefaces in novel ways. For instance, font.fish has a way to explore them in a big scrollable grid.

https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-17-at-7.29.15-AM-1024x817.png

As you explore clusters and axises, you can see how the groupings work and perhaps find what you need by virtue of similarity and variation in what you need.
https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-17-at-7.29.46-AM-1024x277.png
Sweetfont has a different approach where you move around on different axises like from Loud to Quiet or from Playful to Formal. Then ultimately just see one particular font that fits the bill.
https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-17-at-7.31.57-AM-1024x353.png
A more traditional way to organize fonts is to just make broad relatable categories, like Typographer does.

https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-17-at-9.56.47-AM-268x1024.png

And to be fair, Google Fonts does have that, too. They’ve come a long way.
https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-17-at-9.58.58-AM-1024x809.png
But nothing sells a font like a good ol fashioned specimen page. It’s hard for me to look at practical any specimen page and not be sold on it. For instance, I’d love to work on a product that got to use MD UI.
https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-17-at-10.01.26-AM-1024x656.png
Maybe typeface specimen pages could be like a whole coffee table book? That would be sweet. Oh, wait, Elliot Jay Stocks is already all over it.
https://blog.codepen.io/wp-content/uploads/2026/05/otbessivubeth7kkfefx.jpg

How many simultaneous touches can your smartphone detect? 📱

CodePen Blog
426: Browserslist in CodePen 2.0

Stephen and Chris chat about how the 2.0 editor (well, the compiler really) understands and supports Browserslist, a config format that lives in your package.json file that multiple blocks can understand and make browser support decisions against.

Jump Links
* 00:00:07 Talking Browserslist
* 00:07:00 Sponsor: Notion
* 00:08:51 CodePen v2 supports Browserslist
* 00:13:05 Editor config file considered for CodePen
* 00:14:09 How we got this working in CodePen blocks and compiler

Interactive guide: HTML dialog tag for beginners

<dialog id="myDialog">
  <h3>Delete account?</h3>
  <p>This cannot be undone.</p>
  <button onclick="myDialog.close()">Cancel</button>
  <button>Confirm</button>
</dialog>

<button onclick="myDialog.showModal()">
  Delete account
</button>

CSS (optional )

dialog {
  border-radius: 12px;
  border: 1px solid #ddd;
  padding: 24px;
  min-width: 320px;
}

dialog::backdrop {
  background: rgba(0, 0, 0, 0.5);
}

What kind of codes are interesting for you? Write in the comments!

CodePen Blog
427: Next.js and The Journey of SSR

Having that first response from the server to users browsers be, ya know, full of good, useful, renderable HTML is certainly better than an empty

. You can feel it and see it in the filmstrip view of the site loading. Not to mention you need it for at least things like tags if you want your URLs to “unfurl” properly on social sites.

Stephen and Chris jump on the podcast to discuss this journey for us as it relates to Next.js. We got it “for free” for our Ruby on Rails pages, but as we’re slowly changing frameworks over the years, we’ve got new challenges, and some gray-hair inducing bugs.

We started on Next.js’ “page router” and made changes to our Apollo Cache setup to support SSR. Then, over time, moved to the “app router” and did lots more work getting ready getting the most complex page on our site, the 2.0 editor, completely SSRd. That meant getting rid of using things like localStorage for anything view related and fighting bugs related to React somehow mounting itself to the wrong root.

Time Jumps
* 00:00:07 We’re talking Server Side Rendering
* 00:04:33 Why we chose Next.JS
* 00:05:44 Why are we doing SSR?
* 00:07:16 Our phases of SSR
* 00:19:44 Porting the editor page to SSR
* 00:28:08 Handling code folding

Liquid physics using SVG Gooey filters and HTML5 Web Audio API. 🧪✨

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