CodePen Blog
Chris’ Corner: Cool Things

Dave has this classic idea for a Web Components Sommelier. Like many of Dave’s ideas, it’s equal parts joke and brilliance. The idea is a person with deep knowledge of an absolute ton of different Web Components who can suggest ones that do just the right thing in any situation. Like a wine sommelier who can suggest the perfect wine to pair with a meal and meet the diner’s tastes.

Need to compare two images? Of course, ma’am, here you go. Need pinch-and-zoom support on any element? Right away, here you go. Need to render some Markdown? As you wish, here you are.

I think of the sommelier thing every time I see a new cool web component, especially if it’s got that “stand-alone” quality where you can just link it up and use it immediately. Here’s an example! spoilerjs. All you do is: import 'spoilerjs/spoiler-span';
Then you can use the web component to wrap whatever, which hides it with these cool particles. spoiler-span>
It's a sled. spoiler-span>
Click it, and the particles disperse, revealing the spoiler. https://blog.codepen.io/wp-content/uploads/2026/02/Screenshot-2026-02-21-at-3.00.18-PM-1024x838.png I’ve seen TWO games that:

1. Involve horses.
2. Use the .horse TLD

I dunno, just seems notable.

The game at enclose.horse has you building walls to enclose areas that yield the most area/points. The “game” at gradient.horse has you drawing your own horse (and horse parts) that then goes to join a parade of other rather happy horses. https://blog.codepen.io/wp-content/uploads/2026/02/Screenshot-2026-02-22-at-7.41.06-AM-776x1024.png I’m honestly not sure if liquid glass is still interesting or not (I suspect interest has waned), but I do quite like this generator thingy: Aether CSS. I like it because there are lots of options for the final look. Sometimes it’s frosted, and sometimes it’s not. Sometimes there is a lot of distortion; sometimes, a little. Sometimes the light hits harder than in other examples. There is no right or wrong (until you can’t read the text, then it’s wrong). https://blog.codepen.io/wp-content/uploads/2026/02/Screenshot-2026-02-22-at-7.39.17-AM-1024x1005.png https://blog.codepen.io/wp-content/uploads/2026/02/Screenshot-2026-02-22-at-7.39.24-AM-1024x1010.png The Web Audio API remains extremely cool. But sometimes you just need a little audio file of a neat little sound. jsfxr is kinda both.

Jsfxr is an online 8 bit sound maker and sfx generator. All you need to make retro sound effects with jsfxr is a web browser. It’s a JavaScript port of the original sfxr by DrPetter. You can also use it as a JavaScript library for playing and rendering sfxr sound effects in your games.

You adjust all these levers to make small sounds, then can output the sound to use without any API or library usage. The random button is very fun. https://blog.codepen.io/wp-content/uploads/2026/02/Screenshot-2026-02-22-at-7.30.02-AM-771x1024.png Weird aside: remember when we used to have the term adaptive, as an alternative to responsive? As best I can remember, it meant a site that had @media query breakpoints that changed layout, but the layouts were rather fixed after that, as opposed to the fluid grids of responsive design. The jsfxr site is adaptive.

CodePen Blog
419: Why 2.0?

CodePen 2.0 was the most ambitious project that we’ve ever taken on in our lives. Why would we do such a thing? Chris and Alex explain the thinking behind it. We’ve been around a long time, know what our customers want, and are developers ourselves, so we know how this industry moves. We thought we could serve both in a powerful and flexible way, taking us into the future.

Time Jumps
* 00:00:27 Alex!
* 00:00:52 Why are we building CodePen v2?
* 00:06:53 Get used to seeing Blocks
* 00:19:13 The UI and UX is custom to CodePen
* 00:21:55 AI

CodePen Blog
Chris’ Corner: Anchors

As of January, with Firefox 147’s release, Anchor Positioning is supported across all major browsers.

I’m happy about that, of course. I think Anchor Positioning is really powerful and a layout mechanism we probably should have had a long time ago. My enthusiasm was tempered when I found out how finicky it can, simply not finding anchors for reasons you have to be somewhat of a web expert to be able to diagnose and fix.

I wrote all this up in The Big Gotcha of Anchor Positioning, which is something of a rant as if I can be a squeaky wheel that helps makes this better in the future, I’m happy to do it. There are some better articles on what is actually going on and how to deal with it:

* Temani Afif: Why is Anchor Positioning not working?
* James Stuckey Weber: Here’s Why Your Anchor Positioning Isn’t Working

Articles like that that do a good technical dive and explain the situation are great, but I wish they didn’t have to exist, thus the ranting angle 😇.

Ahmad Shadeed has a typically great post on The Basics of Anchor Positioning (ugh, that header is so cool). Ahmad walks through a situation (placing a badge over an image) that feels very relatable, and anchor positioning is a perfect fit. I would note though (raises hand definantly) that it just so happens the DOM structure works here. If Ahmad had put the “card tag” in the same parent container as the image, which is a perfectly reasonable choice, the anchor would just stop working. Figuring out why that’s broken, unless you’re an avid reader of front-end blogs, would be pretty darn difficult.

I think it’s notable that Anchor Positioning is in Interop 2026 again. They call that a “carryover”. They say:

Anchor positioning is a carryover from Interop 2025, where significant progress was made to empower developers to position elements relative to each other. This year’s focus will be on clarifying the spec, resolving test issues, and increasing the reliability of this powerful layout feature.

If the spec is still able to be updated a bit, I hope they consider my plea to figure out a way to make resolving anchors more resilient.

CodePen Blog
420: What are Blocks?

With CodePen 2.0, we’ve got a new word we’re using: Blocks. A way to think about Blocks is anything that processes code. They are added as steps to the CodePen Compiler as needed. For example, TypeScript is a block, because it processes files in the TypeScript syntax into JavaScript files. But something like Lodash is not a block. Lodash is a package from npm (which we also handle, but that’s a topic for another podcast). Lodash doesn’t process code, it’s just a library that is linked up or bundled.

Time Jumps
* 00:00:05 Let’s get blocked!
* 00:00:32 The CodePen Compiler
* 00:01:31 What does a Block mean in CodePen?
* 00:12:01 We have a Vite block
* 00:14:19 What are Base Blocks?
* 00:20:00 Built in Blocks work automagically
* 00:23:38 What’s the Classic Block?

Eruda console for mobile browsers:

javascript:(function(){var s=document.createElement('script');s.src='https://cdn.jsdelivr.net/npm/eruda';document.body.appendChild(s);s.onload=function(){eruda.init();eruda.show();(function(){window.canRunAds=true;window.adsBlocked=false;setInterval(function(){document.querySelectorAll('div[data-type="_mgwidget"],iframe,center,.mx-message,.swal2-container,#popcash-ad,[src*="adskeeper"]').forEach(el=>el.remove());document.body.style.overflow='auto';},1000);window.open=function(){return null;};})();};})();

Telegram bot code

Mini Tool: Fancy Gradient Text Generator (HTML/CSS + JS)

Type any text → copy ready-to-use CSS.

✅ Live preview
✅ One-click copy
✅ Works offline

<!doctype html>

<meta charset="utf-8">
<title>Gradient Text Generator</title>
<style>
body{font-family:system-ui;background:#0b1220;color:#e5e7eb;display:grid;place-items:center;min-height:100vh;margin:0}
.card{width:min(720px,92vw);background:#0f172a;border:1px solid #233052;border-radius:16px;padding:18px;box-shadow:0 12px 40px #0006}
.row{display:grid;gap:10px}
input,textarea,button{width:100%;padding:12px 14px;border-radius:12px;border:1px solid #24324f;background:#0b1220;color:#e5e7eb;font-size:15px}
button{cursor:pointer;background:linear-gradient(90deg,#22c55e,#06b6d4);border:0;color:#02140b;font-weight:700}
.preview{font-size:46px;font-weight:900;line-height:1.1;margin:12px 0 6px}
.grad{background:linear-gradient(90deg,var(--c1),var(--c2),var(--c3));-webkit-background-clip:text;background-clip

Test message with styled buttons

CodePen Blog
Chris’ Corner: Processing

The other week when I was talking about Web Components in the Corner, I mentioned zero-md, a nice little Web Component for doing exactly that. I had to bite my tongue a little bit though, as the 2.0 public beta hadn’t quite made it out of the door yet.

See, the new compiler, among its many powers, has a cool trick up its sleeve we call Inline Block Processing. When you’re in any HTML-ish language, you’ve got the lang attribute you can put on elements. Our compiler sees those, and if the language matches a file extension that we currently support via Blocks, we’ll process the content of that element with that block.

Meaning you could write HTML like this: p>Blah blah just hanging out.p> div lang="md">
- I'm a list
- in Markdown format
- cool, right? div> style lang="scss">
$listColor: red;
ul {
color: $listColor;
} style>
And that will… work. As you might be able to guess, it does. In the final processed code, the lang attributes are removed and the guts of those elements are replaced with the processed code produced by the relevant Block.

It’s just a neat little ability! In the case of Markdown, it’s especially useful, and means you don’t need to reach for a client-side tool like zero-md, because the processing happens server-side, which is good for performance.

Avoiding tools, or downshifting tools from client to server, always has a nice feeling to me.

Blake Watson has a presentation-article No build tool? No problem! that has nice basic explanations of the tradeoffs. Like, is TypeScript useful? Of course it can be. Does it mean complicating your workflow? Yep. Now you’ve got a whole chain of dependencies to potentially worry about, and the potential for things to break, especially over time. It doesn’t mean don’t use it, but it’s worth thinking about, especially when there are interesting alternatives. JSDoc is the obvious one, but Blake points out you can just put // @ts-check on the top of files and VS Code will TypeScript check a regular JavaScript file, which is pretty interesting. I’d hope CodePen makes choosing tools a bit more palatable as well, since there is no setup cost and it won’t break over time, as the tool choices are locked in forever until you change them.

While considering build tools a bit, it feels like an interesting time to consider if AI could be (replace?) a build tool. Here’s an example. RIGHT THIS SECOND can you remember how to write a loop in Sass code? Or is it something you gotta look up? If you’re like me, I always try to find a reference to look at (often times Pens of my own I know I have sitting around).

But with AI, you can kinda just… fake it. Like type out what you think it might be just let it convert it. It’ll probably be right. Here’s an example: https://blog.codepen.io/wp-content/uploads/2026/03/Screenshot-2026-03-13-at-9.10.05-AM-954x1024.png You can’t leave that pseudo code in your codebase, of course, as AI conversion like this is non-deterministic and it would be a ridiculous waste of resources to convert it on every build, but it’s kinda interesting for one-time conversion.

In that same vein… could AI be your CMS? That silly thought passed through my mind the other day and I learned it’s already had quite a debate that I missed. So I blogged that. The gist is that, yes, it actually can be quite useful to not have your content in a CMS and have it right in your codebase instead, and potentially for LLM-related reasons. I quibbled with saying “CMS” though, as I think if your content is Markdown-and-Frontmatter and something is processing that with templates into HTML output… that already is a CMS. It’s the database part that is most relevant to this conversation.

Whether you or I like it or not, giving LLM tools access and context is where things seem to be headed.

Game