CodePen Blog
412: 2.0 Embedded Pens

Or just “Embeds” as we more frequently refer to them as. Stephen and Chris talk about the fairly meaty project which was re-writing our Embeds for a CodePen 2.0 world. No longer can we assume Pens are just one HTML, CSS, and JavaScript “file”, so they needed a bit of a redesign, but doing as little as possible so that existing Embed Themes still work. This was plenty tricky as it was a re-write from Rails to Next.js, with everything needing to be Server-Side Rendered and as lightweight as possible (thank urql!).

Time Jumps
* 00:06 Welcome back to CodePen Land
* 00:35 What’s new about Pens in CodePen 2.0
* 05:20 Designing with custom themes in mind
* 10:40 What the editor looks like in the 2.0 Editor
* 16:09 Converting old Pens to new Pens
* 17:20 Debating using Apollo in embeds

CodePen Blog
Chris’ Corner: Design (and you’re going to like it)

Damning opening words from Edwin Heathcote in Why designers abandoned their dreams of changing the world.

Every single thing on Earth not produced by nature had been designed. That was the spiel. Design wanted it all. Now Earth is a mess, its climate warming rapidly, its seas full of waste. There are microplastics in the glaciers, the air is polluted and forests are being destroyed to make more stuff. If everything is design, then design is responsible for all of it.

The situation is, if you wanna make money doing design work, you’re probably going to be making it from some company hurting the world, making both you and them complicit. Kinda dark. But maybe it is course correction for designers thinking they are the world’s salvation, a swing too far in the other direction.

This pairs very nicely with Pavel Samsonov’s UX so bad that it’s illegal, again opening with a banger:

Once upon a time, there was a consensus about the design process: we would do research to understand user needs, and then we would do design to satisfy those needs. That consensus, it seems, is gone.  From Cory Doctorow’s thesis on enshittification to Ed Zitron’s Rot Economy to the no-consent culture of AI, the trend is clear. “Users should be thankful for what they get,” say our corporate overlords. “Any problems are their own fault, and nothing to do with us.”

Big companies products are so dominant that users are simply going to use them no matter what. Young designers will be hired to make the products more profitable no matter what, and they will like it, damn it.

Using design to make money is, well, often kind of the point. And I personally take no issue with that. I do take issue with using design for intentional harm. I take issue with using the power of design to influence users to make decisions against their own better judgement.

It makes me think of the toy catalog that showed up at my house from Amazon recently. It’s early October. Christmas is 3 months away, but the message is clear: get your wallets ready. This design artifact, for children, chockablock with every toy under the sun, to set their desire ablaze, to ensure temper tantrums for until the temporary soothing that only a parent clicking a Buy Now button gives. It isn’t asking kids to thoughtfully pick out a toy they might want, it’s says give me them all, I want every last thing. The pages are nicely designed with great photography. A designer make the argument: let’s set all the pages on white with product cutouts and plenty of white space, so kids can easily visibly circle all the things they want. Let their fingers bleed with capitalism. Making a list isn’t just implied though, the first page is a thicker-weight paper that is a literal 15-item wish list page designed to be filled out and torn out. More. Morrrreeeee. And just as a little cherry on top, it’s a sticker book too. It begs to travel with you, becoming an accessory to the season.

It’s cocaine for children with the same mandates as the Instagram algorithm is for older kids and adults.

CodePen Blog
413: Still indie after all these years

We’re over 13 years old as a company now. We decide that we’re not a startup anymore (we’re a “small business” with big dreams) but we are still indie. We’ve seen trends come and go. We just do what we do, knowing the tradeoffs, and plan to keep getting better as long as we can.

Links

* Timeline – Chris Coyier
* 115: Adam Argyle on Cracking the 2025 Web Dev Interview | Front-End Fire

Time Jumps
* 00:05 Are we still an indie startup?
* 04:32 Remote working at CodePen
* 19:20 Progressing and advancement in a small business
* 22:51 Career opportunities in tech
* 25:39 Startups starting at free
* 29:17 2.0 for the future

💻 Computer Hardware

Hardware is the physical parts of a computer — things you can see and touch.

⚙️ Main parts:

🧠 CPU – brain of the computer
💾 RAM – temporary memory
📂 HDD/SSD – permanent storage
🧩 Motherboard – connects all parts
🔌 Power Supply – gives electricity
⌨️🖱 Input devices – keyboard, mouse
🖥🔊 Output devices – monitor, speakers

🧠 Hardware + Software = Working Computer

#Informatics #ComputerBasics #Hardware #Tech

CodePen Blog
Google Chrome & Iframe `allow` Permissions Problems

If you’re a CodePen user, this shouldn’t affect you aside from potentially seeing some console noise while we work this out. Carry on!

At CodePen we have Embedded Pens which are shown in an . These contain user-authored code at a non-same-origin URL as where they are placed. We like to be both safe and as permissive as possible with what we allow users to build and test.

The sandbox attribute helps us with safety and while there are some issues with it that we’ll get to later, this is mostly about the allow attribute.

Here’s an example.

A user wants to use the navigator.clipboard.writeText() API. So they write JavaScript like: button.onclick = async () => {
try {
await navigator.clipboard.writeText(`some text`);
console.log('Content copied to clipboard');
} catch (err) {
console.error('Failed to copy: ', err);
}
}
The Embedded Pen is placed on arbitrary origins, for example: chriscoyier.net. The src of the is at codepen.io, so there is an origin mismatch there. The JavaScript in the iframe is not same-origin JavaScript, thus is subject to permissions policies.

If CodePen were to not use the allow attribute on our it would throw an error when the user tries to execute that JavaScript.
Failed to copy: NotAllowedError: Failed to execute 'writeText' on 'Clipboard': The Clipboard API has been blocked because of a permissions policy applied to the current document. See https://crbug.com/414348233 for more details.
This is an easy fix. We make sure that allow attribute is on the , like this, targeting the exact feature we want to allow at any origin: But here’s where the problem comes in… The (new) Nested Iframe Issue

CodePen has Embedded Pens are actually nested s in a structure like this: https://blog.codepen.io/wp-content/uploads/2025/10/Screenshot-2025-10-20-at-8.14.21-AM-1024x499.png In code structured like this: CodePen UI User-Authored Code We need to put the allow attribute on the user-authored code, so it works, like this: CodePen UI User-Authored Code This is the problem!

As soon as the nested iframe has the allow attribute, as of recently (seems like Chrome 136) this will throw an error:
[Violation] Potential permissions policy violation: clipboard-write is not allowed in this document.
With our complete list (which I’ll include below), this error list is very intense: https://blog.codepen.io/wp-content/uploads/2025/10/Screenshot-2025-10-20-at-9.17.16-AM-1024x562.png Can’t we just put the allow attributes on both s? Yes and no.

Now we run into a second problem that we’ve been working around for many years.

That problem is that every browser has a different set of allow attribute values that is supports. If you use a value that isn’t supported, it throws console errors or warnings about those attributes. This is noisy or scary to users who might think it’s their own code causing the issue, and it’s entirely outside of their (or our) control. The list of allow values for Google Chrome

We know we need all these to allow users to test browser APIs. This list is constantly being adjusted with new APIs, often that our users ask for directly. There are even some quite-new AI-related attributes in there reflecting brand new browser APIs. Example of allow value errors

If were to ship those allow attribute values on all s that we generate for Embedded Pens, here’s what it would look like in Firefox: https://blog.codepen.io/wp-content/uploads/2025/10/Screenshot-2025-10-20-at-9.36.05-AM-1024x[...]

509.png At the moment, Firefox actually displays three sets of these warning. That’s a lot of console noise.
Safari, at the moment, isn’t displaying errors or warnings about unsupported allow attribute values, but I believe they have in the past.

Chrome itself throws warnings. If I include an unknown policy like fartsandwich, it will throw a warning like:
Unrecognized feature: 'fartsandwich'.
Those AI-related attributes require a trial which also throw warnings, so most users get that noise as well. https://blog.codepen.io/wp-content/uploads/2025/10/Screenshot-2025-10-20-at-10.10.41-AM-1024x198.png We (sorry!) Need To Do User-Agent Sniffing

To avoid all this noise and stop scaring users, we detect the user-agent (client-side) and generate the iframe attributes based on what browser we’re pretty sure it is. Here’s our current data and choices for the allow attribute export default {
allowAttributes: {
chrome: [
'accelerometer',
'bluetooth',
'camera',
'clipboard-read',
'clipboard-write',
'display-capture',
'encrypted-media',
'geolocation',
'gyroscope',
'language-detector',
'language-model',
'microphone',
'midi',
'rewriter',
'serial',
'summarizer',
'translator',
'web-share',
'writer',
'xr-spatial-tracking'
],
firefox: [
'camera',
'display-capture',
'geolocation',
'microphone',
'web-share'
],
default: [
'accelerometer',
'ambient-light-sensor',
'camera',
'display-capture',
'encrypted-media',
'geolocation',
'gyroscope',
'microphone',
'midi',
'payment',
'serial',
'vr',
'web-share',
'xr-spatial-tracking'
]
}
};
We’ve been around long enough to know that user-agent sniffing is rife with problems. And also around long enough that you gotta do what you gotta do to solve problems. We’ve been doing this for many years and while we don’t love it, it’s mostly worked. The User-Agent Sniffing Happens on the Client CodePen has a couple of features where the is provided directly, not generated.

1. Direct embeds. Users choose this in situations where they can’t run JavaScript directly on the page it’s going (e.g. RSS, restrictive CMSs, etc)
2. oEmbed API. This returns an to be embedded via a server-side call.

The nested structure of our embeds has helped us here where we have that first level of iframe to attempt to run the user-agent sniff an apply the correct allow attributes to the internal iframe.

The problem now is that if we’re expected to provide the allow attributes directly, we can’t know which set of attributes to provide, because any browser in the world could potentially be loading that iframe. Solutions? Are the allow attributes on “parent” iframes really necessary?

Was this a regression? Or is this a feature? It sorta seems like the issue is that it’s possible for nested iframes to loosen permissions on a parent, which could be a security issue? It would be good to know where we fall here. Could browsers just stop erroring or warning about unsupported allow attributes? Looks like that’s what Safari is doing and that seems OK?

If this is the case, we could just ship the complete set of allow attributes to all browsers. A little verbose but prevents needing to user-agent sniff.

This could also help with the problem of needing to “keep up” with these attributes quite as much. For example, if Firefox starts to support the “rewriter” value, then it’ll just start working. This is better than some confused or disappointed user writing to support about it. Even being rather engaged with web platform news, we find it hard to catch when these very niche features evolve and need iframe attribute changes. Could [...]

Is this website design good for you?

CodePen Blog
414: Apollo (and the Almighty Cache)

Rachel and Chris jump on the show to talk about a bit of client-side technology we use: Apollo. We use it because we have a GraphQL API and Apollo helps us write queries and mutations that go through that API. It slots in quite nicely with our React front-end, providing hooks we use to do the data work we need to do when we need to do it. Plus we get typed data all the way through.

Chris gets to learn that the Apollo Cache isn’t some bonus feature that just helps makes things faster, but an inevitable and deeply integrated feature into how this whole thing works.

Time Jumps
* 00:06 How do you get data into the front end of your application?
* 02:57 Do we use Apollo Server?
* 10:17 Why is GraphQL not as cool anymore?
* 18:23 How does the Apollo Client cache work?

CodePen Blog
415: Babel Choices

Robert and Chris hop on the show to talk about choices we’ve had to make around Babel.

Probably the best way to use Babel is to just use the @babel/preset-env plugin so you get modern JavaScript features processed down to a level of browser support you find comfortable. But Babel supports all sorts of plugins, and in our Classic Editor, all you do is select “Babel” from a dropdown menu and that’s it. You don’t see the config nor can you change it, and that config we use does not use preset env.

So we’re in an interesting position with the 2.0 editor. We want to give new Pens, which do support editable configs, a good modern config, and we want all converted Classic Pens a config that doesn’t break anything. There is some ultra-old cruft in that old config, and supporting all of it felt kinda silly. We could support a “legacy” Babel block that does support all of it, but so far, we’ve decided to just provide a config that handles the vast majority of old stuff, while using the same Babel block that everyone will get on day one.

We’re still in the midst of working on our conversion code an verifying the output of loads of Classic Pens, so we’ll see how it goes!

Time Jumps
* 00:15 New editor and blocks at CodePen
* 04:10 Dealing with versioning in blocks
* 14:44 What the ‘tweener plugin does
* 19:31 What we did with Sass?
* 22:10 Trying to understand the TC39 process
* 27:41 JavaScript and APIs