CodePen Blog
411: The Power of Tree-Sitter
Alex and Chris hop on the show to talk about a bit of technology that Alex calls “The 2nd best technological choice he’s ever made.” That technology is called Tree-sitter. It’s a code parsing tool for building ASTs (Abstract Syntax Trees) out of code. GitHub uses it to power search and “go to” functionality. The creators now work on Zen, where a code parser is paramount. We use it to understand an entire Pen very quickly so we can understand how it all links together (among other things) and make a plan for how to process the Pen (a “build plan”). It’s fast, accurate, forgiving, and extensible. Just a heck of a learning curve.
Jump Links
* 00:07 CodePen 2.0 is more than just a fresh coat of paint
* 03:00 Treesitter explained
* 12:04 Making the right choices with technology
* 21:50 How we parse your code
* 26:10 We don’t want you to have to be in config hell
* 28:48 Type type type stop see what happens
411: The Power of Tree-Sitter
Alex and Chris hop on the show to talk about a bit of technology that Alex calls “The 2nd best technological choice he’s ever made.” That technology is called Tree-sitter. It’s a code parsing tool for building ASTs (Abstract Syntax Trees) out of code. GitHub uses it to power search and “go to” functionality. The creators now work on Zen, where a code parser is paramount. We use it to understand an entire Pen very quickly so we can understand how it all links together (among other things) and make a plan for how to process the Pen (a “build plan”). It’s fast, accurate, forgiving, and extensible. Just a heck of a learning curve.
Jump Links
* 00:07 CodePen 2.0 is more than just a fresh coat of paint
* 03:00 Treesitter explained
* 12:04 Making the right choices with technology
* 21:50 How we parse your code
* 26:10 We don’t want you to have to be in config hell
* 28:48 Type type type stop see what happens
CodePen
411: The Power of Tree-Sitter
Alex and Chris hop on the show to talk about a bit of technology that Alex calls “The 2nd best technological choice he’s ever made.” That technology is called Tree-sitter. It̵…
CodePen Blog
Chris’ Corner: Discontent
Nothing is above a little healthy criticism.
Here’s Den Odell’s article We Keep Reinventing CSS, but Styling Was Never the Problem.
It’s easy to forget what CSS was originally designed for: documents. You’d write some HTML, style a few headings and paragraphs, maybe float an image to the left, and call it a day. In that world, global styles made sense. The cascade was helpful. Inheritance was elegant.
Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications, still with a language meant to style a résumé in the early 2000s.
CSS wasn’t built for encapsulated components. It wasn’t built for dynamic theming or runtime configuration or hydration mismatches. So we’ve spent years bolting on strategies to make it work.
If I can critique the critique, it makes some good and astute points, but pitting CSS evolution as the enemy up front doesn’t sit right. CSS itself, in my opinion, is doing great. It’s not the job of CSS to chase trends or bend toward fickle developer tooling trends. To be fair, Den also says it’s not really the fault of CSS, it’s a matter of choosing trade-offs with your eyes open, which I fully agree with.
Jono Alderson isn’t pleased, really, with modern web development entirely. I’ll quote some of his intro:
Most websites are awful.
Not just slow – awful. Bloated, fragile, over-engineered disasters. They load slowly, render erratically, and hide their content behind megabytes of JavaScript. They glitch on mobile. They frustrate users and confuse search engines. They’re impossible to maintain. And somehow, we’re calling this progress. […]
This isn’t evolution. It’s self-inflicted complexity. And we’ve normalised it – because somewhere along the way, we started building websites for developers, not for users.
Go look around at “modern” media-driven sites and you’ll see he’s not wrong. We all see it every day. It’s almost embarrassing these days to tell people you make websites, because everybody knows websites are pretty rough these days.
If I can, again, critique the critique, it’s that nobody (you, me, Jono) need to do this. The web isn’t forcing us to do this. The web is amazingly backward compatible. If you are nostalgic for some way of building websites gone by, well, just start doing it that way again, because it will still work. Jono does mention this, but misses naming the real enemy: the companies themselves that put up with this and hire specifically to enforce it. I can and do say you don’t need to build websites with the latest in JavaScript cargo-culting, but in order to get a decent paying job in web development, well, you just might have to. That’s the real shame here. Yes this is a problem, and we’re not going to fix it unless companies start writing checks to employees to remove cruft and remove complexity and give freedom to developers who care to improve the situation.
For a random little bonus… ain’t it a shame the lack of love for
Chris’ Corner: Discontent
Nothing is above a little healthy criticism.
Here’s Den Odell’s article We Keep Reinventing CSS, but Styling Was Never the Problem.
It’s easy to forget what CSS was originally designed for: documents. You’d write some HTML, style a few headings and paragraphs, maybe float an image to the left, and call it a day. In that world, global styles made sense. The cascade was helpful. Inheritance was elegant.
Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications, still with a language meant to style a résumé in the early 2000s.
CSS wasn’t built for encapsulated components. It wasn’t built for dynamic theming or runtime configuration or hydration mismatches. So we’ve spent years bolting on strategies to make it work.
If I can critique the critique, it makes some good and astute points, but pitting CSS evolution as the enemy up front doesn’t sit right. CSS itself, in my opinion, is doing great. It’s not the job of CSS to chase trends or bend toward fickle developer tooling trends. To be fair, Den also says it’s not really the fault of CSS, it’s a matter of choosing trade-offs with your eyes open, which I fully agree with.
Jono Alderson isn’t pleased, really, with modern web development entirely. I’ll quote some of his intro:
Most websites are awful.
Not just slow – awful. Bloated, fragile, over-engineered disasters. They load slowly, render erratically, and hide their content behind megabytes of JavaScript. They glitch on mobile. They frustrate users and confuse search engines. They’re impossible to maintain. And somehow, we’re calling this progress. […]
This isn’t evolution. It’s self-inflicted complexity. And we’ve normalised it – because somewhere along the way, we started building websites for developers, not for users.
Go look around at “modern” media-driven sites and you’ll see he’s not wrong. We all see it every day. It’s almost embarrassing these days to tell people you make websites, because everybody knows websites are pretty rough these days.
If I can, again, critique the critique, it’s that nobody (you, me, Jono) need to do this. The web isn’t forcing us to do this. The web is amazingly backward compatible. If you are nostalgic for some way of building websites gone by, well, just start doing it that way again, because it will still work. Jono does mention this, but misses naming the real enemy: the companies themselves that put up with this and hire specifically to enforce it. I can and do say you don’t need to build websites with the latest in JavaScript cargo-culting, but in order to get a decent paying job in web development, well, you just might have to. That’s the real shame here. Yes this is a problem, and we’re not going to fix it unless companies start writing checks to employees to remove cruft and remove complexity and give freedom to developers who care to improve the situation.
For a random little bonus… ain’t it a shame the lack of love for
sin() and cos() in CSS? Most hated?! Jeepers.CodePen
Chris’ Corner: Discontent
Nothing is above a little healthy criticism. Here’s Den Odell’s article We Keep Reinventing CSS, but Styling Was Never the Problem. It’s easy to forget what CSS was originally designed …
Html codes
Photo
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
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
From which network did the early form of the Internet evolve?
Anonymous Quiz
0%
Ethernet
17%
Internet
67%
ARPANET
17%
WI-FI
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.
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
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 spi…
Html codes
Photo
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
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
What does this do? <input type='email' required>
Anonymous Quiz
17%
Accepts only numbers
67%
Accepts email format only and is required
17%
Sends an email automatically
0%
Does nothing
💻 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
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
Html codes
Photo
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
Here’s an example.
A user wants to use the
The Embedded Pen is placed on arbitrary origins, for example:
If CodePen were to not use the
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
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:
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
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
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
If were to ship those
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 IssueCodePen 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 ChromeWe 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 errorsIf 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[...]
Html codes
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…
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 [...]
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 [...]
❤1