CodePen Blog Chris’ Corner: Check It B4 U Wreck It

There is an airport in Bend, Oregon where I live. We’ve got a proper one in Redmond, the next town over, but a little baby municipal one here in Bend. There is a cafe there that I’m only just hearing about: Bend Airport Cafe. Looks nice, I should go!

I’m mentioning it for another reason,though. As soon as I saw that website, I SAW CLAUDE CODE immediately. https://blog.codepen.io/wp-content/uploads/2026/05/claude-1024x411.jpg Tell me I’m not crazy and you’ve seen it too.

This look is everywhere. To my eyes, it’s more prevalent than Bootstrap ever was, Tailwind UI, or even the purple-gradient-text era of crypto and early AI.

I feel like it happened as Anthropic started talking about skills and made their own design skill. The designs coming out of Claude Code are undeniably much nicer, but do look very same-y, like they have some pretty strict prompts baked in that choose between a very limited subset of design choices.

About this particular restaurant website, I feel like it’s quite decent looking and I don’t hate that maybe the design bar for low-end work gets pushed higher because of this, but also HEY EVERYBODY, let’s keep a close watch on all this. These AI slop websites are chockablock with really simple mistakes.

The navigation of the site is mostly jump links like #catering, which work fine when on the homepage. But the “Gallery” page links to /gallery, and when you’re on that page, the jump links don’t work anymore. Even the logo is just a link to #, so when you’re not on the homepage, it doesn’t get you back there.
https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-10.14.13-AM-1024x695.png Now I can’t get back to the homepage from any sub page unless I hand-alter the URL.
I was reading Piccalilli’s in-depth guide to customising lists with CSS and thinking about what a nice touch customized lists are. Oh look, a nice customized list! Nah, just kidding, it’s a totally unsemantic div soup with a bunch of Tailwind classes.

https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-10.14.49-AM-955x1024.png This is so chill to do now on real lists with ::marker.

This is what extra got me going the other day. Then I heard about another restaurant in Bend for the first time: Los Andes. https://blog.codepen.io/wp-content/uploads/2026/05/losandesbend.com_events-777x1024.png I know you can just smell the Claude design skill wafting off that sucker.

It doesn’t just look the same though, it’s full of dumbass simple mistakes. Like the one-field form doesn’t associate the label correctly. https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-12.59.03-PM-1024x564.png The light gray text used isn’t even close to readable, even for someone with strong vision. https://blog.codepen.io/wp-content/uploads/2026/05/CleanShot-2026-05-08-at-12.59.47@2x-1024x640.png There is a little irony to me in that surely Clade Code could help anyone fix these problems so quickly and easily. But either people don’t know they are even problems or don’t care and both of those options are a bummer.

The same-y design choices are such a hilarious tell though. I had it help with a adding design to a Vue Template a while back, and honestly it looks pretty great I think! But it’s 100% that same exact design aesthetic happening here too.

The one-word-is-italic-in-the-header is hilariously common to me, along with the one-button-is-outline-one-is-solid, and the little-tiny all-caps header above headlines. BASK IN IT: https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-08-at-1.05.33-PM-1024x734.png The one that gets me the most is how every “card” style element has a dang hover on it though. It’s just everywhere. And it can be a real problem. It means that sometimes it’s an or

e>wrapping the entire contents of a card, meaning a title, copy, image, etc, which is just silly. Seriously, they need to read this.

Lemme leave you with some good articles.

* Dave writes about approaching light/dark styles at a component level, with optional inversion, made quite simple really.
* Eric writes about the infinity keyword in CSS. I love the use case where using it with word-spacing forces one-word-per-line. Clever.
* Roma writes about Responsive Cyclic Margins with some absolutely wacky clamp/max functions in order to get truncation of text happening at the end of text and before an icon. Just try to get that right, Claude.

CodePen Blog
Chris’ Corner: View Transitions

I’ve had View Transitions on the mind a little bit after experimenting with using them to move the focus ring around the page. I found that pretty satisfying, except the part where I was binding events to the tab key myself and keeping track of “focusable” elements. I know better, as that kind of thing is always best left to the browser. I was just checking whether it was possible to animate that focus style from place to place, since it wasn’t really “the same” element (and arguably not an element at all). It is totally possible.

But then I’m glad Kilian Valkhof chimed in with his CSS-only floating focus with anchor positioning, which pulls it off without needing any JavaScript at all. I guess I still proved it can be done with View Transitions, but certainly Kilian’s demo is much cleaner. Jealous! I should have thought of that.

In my own last demo, I noticed something about the CSS styles I was playing with to control the animations. /* movement */ ::view-transition-group(focus-ring) {
} /* resizing */ ::view-transition-old(focus-ring), ::view-transition-new(focus-ring) {
}
I put those comment labels there, as I happen to notice that if you changed the animation-duration on them to exaggerate things, it seemed the view-transition-group was in charge of the moving and the other two were in charge of the morphing of one shape to another. I honestly don’t even get it. I emailed Cyd to see if she can explain it haha, we’ll see if we get that blog post someday.

I do know that you can see the pseduo element tree of View Transitions stuff in the DOM (via Chrome DevTools) as the animations happen. https://blog.codepen.io/wp-content/uploads/2026/05/Screenshot-2026-05-12-at-8.55.57-AM.png That’s nice, as you can click on them and see what’s what.

But notice how they are all children of the element?

Well, ultimately, that’s because we call document.startViewTransition(). Document. That’s . That’s required for now, but is a proposal to be able to call startViewTransition from other elements, meaning it would be “scoped” down to that element. This allows, for one thing, multiple View Transitions to run at once, which is impossible right now. It’s ready for testing, Chrome says.

The part I like the most about scoped view transitions is that that psuedo element tree we looked at above is placed within the element you call it on, and that element might have something like overflow: hidden on it, and it will actually be respected, as Bramus’ demo clearly demonstrates. It’s nice to be able to experiment and understand how these things work. Thanks, CodePen.

Speaking of Bramus, he’s got a View Transitions Toolkit he’s put out. I haven’t played with it yet, but it looks like it’s got some real practical goodies like detecting support and dealing with the fallback structure and auto-naming functions. But the feature I’d probably use the most is the ability to scrub through the animations. I gave it a shot and found it a little complex to set up, relying on some fairly complex helper functions that aren’t a part of the package itself, but I did get a demo working. https://blog.codepen.io/wp-content/uploads/2026/05/scrub-1024x519.png Let me leave you with Some practical examples of view transitions to elevate your UI — a great article by Declan Chidlow showcasing some extremely practical uses of View Transitions you may not have thought of. Animating the re-sorting of a table is pretty cool, as is animating the progress bar of a multi-step form.

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.)