CodePen Blog
Chris’ Corner: Cursors

CSS has a bunch of cursors already. Chances are, you’re not using them as much as you should be. Well, should is a strong word. I can’t cite any evidence offhand that special cursors is some absolute boon to user experience or accessibility. But it certainly seems like a nice touch. Like:
.copy-button {
cursor: copy;
}
Or
[disabled] {
cursor: not-allowed;
}
These cursors are actually supplied by your OS, and thus can be altered by the OS. That’s a good thing, as some OSs let you bump up the size of the cursor (with a url() value), for example, which is good for accessibility. You can set custom cursors as well, which won’t get bumped up, which is bad for accessibility.

Looking around at our 2.0 Beta editor, I can see lots of CSS-provided cursor changes.
https://blog.codepen.io/wp-content/uploads/2025/11/CleanShot-2025-11-13-at-10.26.48.gif
I’m pretty pleased with those!

An interesting aspect of “custom” cursors is that they are only obviously a problem if you replace the actual cursor itself. That doesn’t rule out doing things in addition or next to the cursor. Our own Rachel Smith’s site has rainbow paint splotches shoot out from behind the cursor, just for fun, but the cursor itself isn’t changed.

Kyle Lambert has a good article about doing useful things with the cursor with a particular focus on things Figma does. Here’s some of excerpts of good ideas:

When using the pen tool, the cursor displays preview points and potential path directions

During selection, the cursor indicates whether you can resize, rotate, or move elements

Each user’s cursor appears as a distinct color with their name attached, creating a sense of presence in the shared workspace. [… and they] act as a chat interface when a user types “/”

One of Figma’s latest features is a dynamic color picker interface. This provides a magnified view of the pixel selection, giving users a more precise color selection experience.

Just interesting stuff! Not sure we’re seeing quite as much cursor innovation elsewhere.

CodePen Blog
417: Iframe Allow Attribute Saga

There was a day not long ago where a Google Chrome browser update left any page with a CodePen Embed on it throwing a whole big pile of red JavaScript errors in the console. Not ideal, obviously.

The change was related to how the browser handles allow attributes on iframes (i.e. ). CodePen was calculating the appropriate values inside an iframe for a nested iframe. That must have been a security issue of sorts, as now those values need to be present on the outside iframe as well.

We documented all this in a blog post so hopefully we could get some attention from Chrome on this, and for other browser makers as well since it affects all of us.

And I posted it on the ol’ social media:
Hi @developer.chrome.com 👋👋😬blog.codepen.io/2025/10/20/g…Having some iframe `allow` issues over here. Not sure if it's a "bug" to log, but we could use an assist.
— Chris Coyier (@chriscoyier.net) 2025-10-20T20:25:43.360Z

Huge thanks to Bramus Van Damme who saw this, triaged it at Chrome, and had a resolution within a day:
I followed up on this one with engineering (issues.chromium.org/issues/45408…), and we decided on a small tweak to only show these console messages when a reporting endpoint is set.The tweak landed in Chrome 143.0.7490.0 (current Canary)(See next message for before and after screenshots)
— Bramus (@bram.us) 2025-10-24T12:21:00.246Z

I think the patch is a great change so hats off to everyone involved for getting it done so quickly. It’s already in Canary and don’t really know when it’ll get the stable but that sure will be good. It follows how Safari is doing things where values that aren’t understood are just ignored (which we think is fine and inline with how HTML normally works).
Fortunately we were able to mitigate the problem a little until then. For most Embedded Pens, a

CodePen Blog
Chris’ Corner: Kagi Blog Typography

I’ve been using Kagi for search for the last many months. I just like the really clean search results. Google search results feel all junked up with ads and credit-bereft AI sludge, like the incentives to provide a useful experience have been overpowered by milking profit and a corporate mandates on making sure your eyeballs see as much AI as possible.

I’m also not convinced Google cares about AI slop. Like do they care if a movie review for Predator: Badlands was written by a human after actually watching the movie, or if Gemini farted out a review because the LLM knows basically what a movie review reads like. Me, I sure would like to know. So I’m pleased with Kagi’s SlopStop idea.

But I’ve managed to start this column with something I didn’t even really intend to talk about.

Naturally, I’d like to talk about the typography one Kagi’s blog (follow that SlopStop link). https://blog.codepen.io/wp-content/uploads/2025/11/Screenshot-2025-11-21-at-10.55.58-AM-1024x604.png Look at those single words at the end of both of those headers. Looks off. I can’t remember if those are “widows” or “orphans”, but upon looking it up, it’s neither, it’s a “runt” (lol).

Obviously we can’t have that.

One option is to text-wrap: balance; on the headers. Here’s what that looks like: https://blog.codepen.io/wp-content/uploads/2025/11/Screenshot-2025-11-21-at-11.09.30-AM-1024x754.png Ehhhhhhhhh. Also not ideal. It makes those headers like half the width of the available space. Balancing is just way nicer with center-aligned headers. Which actually makes me think of how style queries should work with arbitrary styles… h1, h2, h3, h4 { /* doesn't actually work, style
queries only work on
--custom-properties */
@media style(text-align: center) {
text-wrap: balance;
}
}
Whatever — let’s not balance here anyway, let’s try text-wrap: pretty; (which lacks Firefox support). There we go: https://blog.codepen.io/wp-content/uploads/2025/11/Screenshot-2025-11-21-at-11.22.41-AM-1024x608.png Better. The pretty values does a bunch of stuff, and runt-protection is among them.

Honestly though it’s the line-height that bugs me the most. It’s just too much for a big header. Let’s bring it in and even pull the letters a little bit with negative letter-spacing. https://blog.codepen.io/wp-content/uploads/2025/11/Screenshot-2025-11-21-at-11.28.58-AM-1024x857.png Now we’ve got to fight hierarchy and organization a bit. All the text is pure black… fine. Everything is about the same distance away from each other… that’s a little weird. So we’re just leaning on text size and weight (and one little instance of italic).

I think we bring in just a smidge more to help here. Kagi has a wonderful little dog logo, we bring her in on the title so it sets it apart. The nav can set inline with the title. We use the nice yellow brand color to better set the title and date, then let it ride. https://blog.codepen.io/wp-content/uploads/2025/11/Screenshot-2025-11-21-at-11.33.19-AM-1024x939.png They should probably just get a CodePen account to work this stuff out right?

shared_file

CodePen Blog
Chris’ Corner: Web Components

I’d never heard of a CEM before. That’s a “Custom Elements Manifest” or a custom-elements.json file in your project. It’s basically generated documentation about all the web components your project has. Dave calls them the killer feature of web components.

With a Custom Element Manifest, community plugins can use that information to generate files, populate dropdowns, add red squiggles, provide autocomplete, and automate a lot of the mundane meta-system DX work that comes with supporting a component library

I love the idea of essentially getting “free” DX just be generating this file. I particularly like the language server idea so that code editors can offer all the fancy autocomplete and linting for your bespoke elements.

Sometimes web components seem so practical and straightforward, like Eric Meyer’s recent <aside-note. It yanks out some text into another element that gets positioned somewhere new, if a few media queries pass. And sometimes web components scare me, like when you read advice to make sure to have an asynchronous promise-resolving disconnectedCallback that is a mirror image of your connectedCallback because you can’t predict how the DOM will be changed. Maybe it’s best to roll up your sleeves and write your own define functions.

Let’s just take a quick stroll through some web components I saw people writing about recently. I do find it significant there is a low constant simmer of web component writing/sharing like this.

* Lea Verou made a <bluesky-likescomponent. I gave it a whirl just for fun.
* Zach Leatherman took the Web Awesome copy button and incorporated it into the Eleventy docs in his own way, with all the thinking toward performance and progressive enhancement as you’d expect.
* Pontus Horn got all declarative with ThreeJS thanks to web components.
https://blog.codepen.io/wp-content/uploads/2025/11/boxes-1024x575.png

CodePen Blog
Chris’ Corner: HTML

There’s a new term in town: soft navigations. Basically it means “single page app” (SPA) style navigations where page stuff changes, and the URL changes, but the browser didn’t do a traditional full-reload thing. I like the term in the sense that it sounds like a light insult. Whattaya too weak, child, to do a proper page load? Whattaya soft? Anyway the point of it is so that the browser itself has a way to detect these things, and testing Core Web Vitals is the entire reason. That feels like kind of a light reason to introduce a whole new API, but Google invented Core Web Vitals and their in-house initiatives like that get the juice.

And the out-of-house initiatives sometimes get the boot. So when there is a cool new image format in town, like JPEG XL, that isn’t from Google, things get weird. Declan Chidlow wrote about this in JPEG XL and Google’s War Against It. Google invented WebP in-house, so people feel it’s protected over better technology.

This would also partly explain why they adopted AVIF but not JPEG XL. AVIF wasn’t superior in every way and, as such, didn’t threaten to dethrone WebP.

JPEG XL, however, is better than WebP in every quantifiable way and would obsolete it.

But Google can do what they want with Chrome. It’s theirs, after all, a fact just recently confirmed. That’s for the better, if you ask me, but it does serve to tighten the iron grip they have over the web generally.

This is putting me in an HTML-y mood so allow me to share a few more HTML-y things.

I found Alex MacArthur’s article TIL: A Link’s Download Attribute Won’t “Just Work” for Cross-Origin Resources from a few years ago very useful recently. See, you’ll see advice where if you want a link-click on a website to immediately download a file, you just put the download attribute on it, like: a href="/files/thing.pdf" download>Download PDFa>
But what nobody tells you is that if the URL is cross-origin, that just straight up doesn’t work. a href="https://api.site.com/files/thing.pdf" download>Download PDFa>
So thankfully we have people like Alex to dig around and to the research and blog the answer, which is that you need the server to serve that file with a Content-Disposition header. Phew.

Ya know how there’s a little thing people call best practices? Some people seek them out. Some people poke fun at them like they know better. I’m more the former, myself. Be like Chesterton, before you tear down a fence, know why it was built in the first place. The best practices are the fence, see.

A classic best practice is that you don’t duplicate IDs on HTML attributes. You’re told to not do it, but less often, why not to do it. I best most of you could think of at least one reason. Right away I think about how getElementById will only find the first one, which may or may not be what any given code is aiming for. I think about hash links and they’ll only scroll to the first find, which again might be a mis-aim. Other elements that point toward an element with the ID (think for or aria-labelledby) might miss their aim too.

Welp, that’s three. Enough for you? Maybe you think… well those don’t apply to this current website I’m working on. And the fact that a #id selector matches multiple elements just fine in CSS is little a little shrine for you to hang your hat and say you just don’t care about this little “best practice”. Here’s Lee Amador with a couple of more examples. Maybe there are more. But that’s why this is a best practice. Just lock in your brain that you don’t duplicate IDs and you avoid every possible problem with no downside.

Created using Chatgpt 5.2

CodePen Blog
Chris’ Corner: Cloud Four

This is an appreciation post for the Cloud Four Blog. It’s one of those must-subscribes. I find myself adding almost every post they put out to my archive of posts to dig into. So since I’m overflowing with them a bit, and there is a hot-off-the-presses one, I figured I’d share that and a bunch of favorites.

In Responsive Letter Spacing, Tyler Sticka covers a scenario where you want to tighten up letter-spacing, but be smart about it. At big font sizes, some tightening looks good (I put it on my own starter) but at smaller font sizes, it harms readability. Using em is a good start as it scales with the font size automatically, but then it’s better to reduce it as it gets smaller. Fortunately Tyler found a great way to do it with clamp(). * { letter-spacing: clamp(
-0.05em,
calc((1em - 1rem) / -10), 0em
);
}
Great minds think alike as I was thinking about the UI/UX pattern of one-time password inputs lately too. Tyler again here tackles it his own way in Simple One-Time Passcode Inputs. We agree: don’t actually make it multiple elements, as tempting as that is from a styling perspective. There is simply too much JavaScript required to make that work nicely (which can easily break down) and you otherwise get for free if you don’t do that. Instead, use the proper set of attributes on an input for it: input type="text" inputmode="numeric" autocomplete="one-time-code" maxlength="6">
Then just style it with CSS to make it look however you want. That is, apply the input mask with styles alone.

I was just bemoaning the loss of JPEG XL the other day, but in On Container Queries, Responsive Images, and JPEG-XL a couple years back, Jason Grigsby was already in grief. Container Queries, one of the great CSS revelations of our time, is spiritually connected to responsive images in that they want to do the most-appropriate thing with the information available on how they are displayed on the page. You’d think they would get along and share information, but you’d be wrong. We could evolve the syntaxes to help, and probably should, but it’s intereseting that JPEG-XL, and image format, was actually somewhat designed to help with this and would have been a serendipitous gift for web developers, if we actually were able to use it.

Speaking of images, I think we all know we’re not really supposed to be using GIF anymore as the performance sucks and we can replicate it with video. I tend to like the video approach, but there are significant drawbacks to be aware of:

* Colin Bendell pointed out that browsers don’t preload video, which can impact perceived performance.
* By default, the video experience isn’t very GIF-like: You need a magic combination of autoplay, loop, muted and playsinline attributes to achieve similar behavior.
* The video element exposes more playback control possibilities, which can be good for accessibility, but it lacks an alt attribute for alternative text. (The title and fallback content don’t seem to be exposed to assistive devices in a similar way, but maybe aria-label or aria-labelledby would work?)

Tyler looked at alternatives and there are some really strong contenders in the form of newfangled image formats. But (surprise surprise) the browser support story is dicey.

Gerardo Rodriguez talks about Testing HTML Light DOM Web Components: Easier Than Expected! Good to know, really. Testing here meaning load up the component in a browser-like environment and make sure what you expect to be there in the DOM is there and interacting with it does what you expect.

It’s not like you can’t test Web Components that use the Shadow DOM, but in practice it’s an annoying barrier that you have to manually account for in many places, and other [...]

tools need to be aware of and work with as well. Nice to have so uch example code here to reference.

OK fine one more. This is a nice demo of a common web app interaction. It’s a good reminder that we really need to implement “bulk actions” in more places on CodePen properly.

new year.html