CodePen has a prefill API. You POST to it with code you want in the editors (and settings, like preprocessor choices), and we create a new (unsaved) Pen in the Pen Editor. It’s pretty raw though. You need to know how to do a POST request. That can be done right in HTML alone even, but putting a bunch of JSON into a <input type="hidden"> so a <form> can POST it isn’t perhaps the most ergonomic thing in the world.
Sean Wu created a Web Component for this, available as codepen-link. It makes creating an “Open this on CodePen” <button> a lot more ergonomic:
<codepen-link
html="<h1>Hello world</h1>"
title="Open in CodePen"
pen-title="New demo pen"
editors="110"
css-preprocessor="scss"
css="body{ font-family: 'Open Sans', sans-serif; }"
css-external="//fonts.googleapis.com/css?family=Open+Sans:300,400,600,700"
js-external="https://cdn.jsdelivr.net/npm/codepen-link/dist/codepen-link/codepen-link.js"
>
<button type="button">Click me view in Codepen</button>
</codepen-link>
As long as you have the script loaded up, that button does what you expect it to.
As an extreme bit of meta, here’s an embedded Pen showcasing a <codepen-link>, which opens a Pen in which the codepen-link script is also prefilled.
If you have the code you’re trying to prefill on another site (like you would if you’re using this) remember that you can use prefill embeds too, to make an embed out of code/settings that you provide (and don’t need to be saved on CodePen).
When you open up the Embed modal in the Pen Editor, this is where you get the copy-and-paste code for Embedded Pens. You can do lots here, like change the theme, flip on an option to make the embed have a live editor, adjust the height, and also enable the click-to-load feature.
The purpose of the click-to-load feature is to reduce the weight of the Embedded Pen. Rather than seeing the <iframe> preview of your code up front, you see a covered area (that has a screenshot of your preview) and a Run Pen button instead. You click it to literally run the Pen and see the live preview. Here’s a live example:
What changed?
Before this release, the overlay for click-to-play embeds covered the entire embed area. Meaning you couldn’t see anything at all in the embed until you clicked that Run Pen button, then the whole embed loaded up.
After this release, it’s only the preview area that is covered and not rendered until the Run Button is pressed.
The spirit of the original style was to make the Embedded Pen as lightweight as possible. That overall weight depended on the screenshot to some degree, but was generally in the 20 KB range. This new style is around 40 KB. So they are heavier, but ultimately, not by much. What does that buy you?
You can actually see your theme right away
You can see the code (if you have one of them open as a default panel) right away
It’s more useful and more obvious what you are looking at. We think those two things are pretty big improvements and make these click-to-run embeds a lot better. They are still pretty lightweight, and might only be a small fraction of the size of the complete embed once a user runs it. For example, you might be demonstrating some React animation concept. Well, with click-to-run, the user isn’t loading a full blown copy of React and an animation library and incurring the CPU and memory cost of this animation until they want to see it. That’s still a big performance boon.
The Vue team is very performance conscious. They very much preferred the click-to-run version of our embeds (because of the fast-loading), but the experience was too minimal. We worked with them to find a good solution, and ultimately decided this style of click-to-run embed would be best for everyone, so we rolled it out globally.
Anywhere that uses oEmbed will see this version of the embeds also, meaning that all default WordPress embeds, Medium posts, Discourse forum posts… really anywhere that supports oEmbed will have this new, better style of embed:
Oh, and click-to-run works with Editable Embeds and Prefill Embeds as well:
With Editable Embeds, as soon as you click Run Pen, the editor becomes active. This is a big performance savings for those, because Editable Embeds need to load quite a few additional resources to make the live editor work.
With Prefill Embeds, you use data-preview="true" on the wrapping <div> and that will trigger click-to-play mode.
Google has a new Top-Level Domain (TLD) they are offering: .new. They have special requirements for it:
Navigation to a .new domain must bring a user directly into the action generation or online creation flow. Navigation or redirection to a homepage or landing page that requires the user to take additional steps or clicks to initiate action or creation will not be deemed to comply with this policy.
For example, GitHub has repo.new that takes you to a page to create a new repository. Stripe has invoice.new for taking you directly to a page for building an invoice.
Now CodePen has pen.new for taking you straight to the Pen Editor.
Since we applied during the “Limited Registration Period”, we had to fill out an application saying what we would do with it, and fortunately we were approved. After approval, then we could proceed with buying the domain. It’s $500 a year! Google says it’s because it’s a brand new TLD that they’ll need to highly monitor and protect. Pretty pricey for a TLD. Not too many that are more expensive.I guess it’s no .rich
I am definitely not going to buy this.
I think it’s worth it because it’s fun and if it encourages some folks to build that domain into their muscle memory for creating new Pens, that’s a good thing for both of us.
Idea pop into your head? Need to get to the Pen Editor ASAP?
Vue is an extremely popular JavaScript framework! Vue works with a regular ol’ <script> tag linking up the library and your existing HTML and CSS if you’d like it to, so in that sense, Vue already works great with the Pen Editor. Here’s an example of using Vue that way.
But Vue also supports the idea of Single File Components (SFCs), which is also a very popular way to use Vue. These SFCs need to be compiled specially with a build tool like webpack or Browserify, meaning the regular Pen Editor on CodePen can’t really do them.
Good news! We now have a custom editor just for Vue SFCs!
You might want to bookmark that URL for now, as you won’t find a way to this custom editor in the CodePen interface just yet. That’s coming, of course, we just have some work to do to prepare for that.
Listen to our podcast
We chat about this in detail.
Watch our video
If you’d like to see some first-steps from an absolute Vue beginner on how Vue SFCs work, here’s a video I did:
Can’t you use Vue on CodePen without this custom editor?
Yes! You can. Like I mentioned at the top of the article, Vue can work as a JavaScript library on the page in a regular <script> tag, which is a perfectly acceptable way to use Vue (try adding it as an External Resource).
In fact, our Vue Topic is mostly Pens that use Vue in that way for now, although we plan to evolve it to be a mixture of both. You just can’t write Vue in the Single File Component syntax without using this custom editor.
Changing Vue Versions
As I write, Vue 3 isn’t released as a stable version just yet, but you can still play with it here on CodePen! Under Pen Settings you can switch between the latest versions of both:
All the regular features of CodePen
While you create Pens with this custom editor, they are still Pens. You can make them private. They work with Collab and Professor Mode. You can embed them, even editable and prefill embeds work. They are just like any other Pen!
We've just released some key keyboard commands for the Pen Editor that have been highly requested for years: the ability to move from editor to editor.
Command (Mac) / Control (PC) + Option (Alt) + 1: Move focus to the HTML Editor
Command (Mac) / Control (PC) + Option (Alt) + 2: Move focus to the CSS Editor
Command (Mac) / Control (PC) + Option (Alt) + 3: Move focus to the JavaScript Editor
This way if you're the type that really likes to stay on your keyboard at all times, you don't have to lift your hands to move editors.
You can't see my keyboard, but here's a little video showing how I can hop between the editors. Even my cursor position is maintained!
Keyboard commands are tricky on the web because you're balancing multiple operating systems' keyboard commands with multiple browsers keyboard commands. Then at CodePen, we use CodeMirror which has its own set, and Emmet which adds more, and also offer alternate key bindings like Sublime Text and Vim bindings. So we really hope we aren't stomping on someone's very important keyboard command here, but so far so good.
Escape!
Having control over focus is an accessibility consideration too, so I'm also very pleased to say that you can now press the ESC key to move focus out of the editor and onto the settings button for that editor.
After you've escaped, focus is on the settings button you can can pop that open pretty easily, and the next tab is the editor actions.
Hopefully, this makes the editors a bit more accessible and useful in that you can always get focus out of the editor with the keyboard (rather than being trapped in there with no way to get focus out).
Caveats
Vim key bindings make heavy use of the ESC key already for core functionality, so we skip our focus movement when those are active.
You might notice a smidge of extra visual activity happening down in the Pen Editor footer lately. We're trying to show you a bit more information about what the Pen Editor is actually doing.
Here's an example (5 second video) where I'm editing some HTML to include an <em> tag or not, and the editor is doing stuff to make that happen for me:
The idea is to show you (and us!) what is happening in the Pen Editor as we do it. Like sometimes code needs to get processed. Sometimes the preview needs to get rebuilt. Sometimes your code is off being linted or formatted. There is a bunch of stuff that might be going on in the editor, and we wanted a dedicated place to be clear about that rather than having it be a silent mystery.
When you're working in the Pen Editor, you have complete access to both all the files you've uploaded (Asset Hosting is a PRO feature) as well as a slew of free design resources we make available to you.
Click that Assets button in the footer, and the Assets modal will pop up. We've just redesigned this area to be more useful and more in-line with other areas of the site, like our recently redesigned Pen Settings.
The biggest bit of feedback we were working from is that, for PRO members, it was too hard to access your own files. In fact, in some screen sizes and configurations, the Your Files section could have been totally off-screen and it wasn't obvious you could scroll to it. In this new design, Your Files is front-and-center when you open the modal, and all the other free resources are still there and easy to click over to.
The Pen Settings area in the Pen Editor is a highly important bit of UI in CodePen! You'll see this area when doing anything from changing a preprocessor to changing the description of a Pen to turning on and off Auto-Updating.
We're also working on some new features that will ultimately be a part of Pen Settings, so we thought it was time to spruce up the design.
For the most part, things are under the same "tabs" as they used to be, with just a smidge of re-arranging. Things like Code Indentation and Indent Width are "Editor" concerns so we've broken that into its own tab, while Behavior is the remaining things concerning the behavior of the whole Pen. Also, Privacy has its own tab rather than being combined with Pen Details. But the most important little toggle, Public/Private, is available in the footer so can be changed from anywhere.
Note that you'll see different tabs depending on if you own the Pen or not (e.g. you can't change a Pen's title/description/tags if you don't own it, so we don't even show you that tab). You can change other settings as you play with the Pen, just note they won't actually save unless you fork the Pen for yourself.
The JavaScript Editor (in the Pen Editor) is now smarter.
While it used to catch syntax errors (like malformed JavaScript, e.g. var 1 = 2). It will now catch other errors also.
For example:
let buttons = document.querySelectorAl("button");
querySelectorAl isn't a syntax error, it's just an incorrect spelling of a DOM method. It will throw an error. For a long time, in order to see that error, you'd have to open your browser console. CodePen would tell you nothing.
Now, we report that error to you!
We try to be chill about it, as your eyes might spot that typo as you're writing it, and we don't want to cause any weird reflow in your editor or bug you too much. So all you'll see is an error icon in the editor:
Click it to see what's going on:
Note that our in-app Console also has the information now, and may have more details in some cases.
Note: You probably don't need to know any of this and hopefully didn't even notice it.
We used to use the domain s.codepen.io to render previews of the code you write. In the Pen Editor, Details View, Full Page View, and more. Using a different domain (a subdomain in this case) is a very important security aspect of CodePen. If we were executing the code you write on codepen.io itself, that's essentially one massive XSS vulnerability.
We've now updated those same preview iframes to be an entirely different domain. This provides a little bit more security. For example:
Extra-eager password managers won't drop your saved CodePen login and password into Pens that are just demonstrating a <form> design.
There was a rare bug where users would get logged out because their cookie-storage would get over-stuffed from unusual Pens putting things there.
At the moment, we're using cdpn.io as the domain name for the iframe previews, but this may change at any time. We've re-architected this so it's easier for us to move around as needed.
The only reason this might affect you is if you happen to be someone who has written code to detect if the Pen is rendering in a preview area or in a grid and do different things. If you were specifically, for example, regexing the domain name of the iframe for the existence of s.codepen.io and other pathing information, that maybe be broken now. I'm afraid we can't promise the domain name previews render at going forward. At the moment, the path /fullpage/ is included in the URL which was used before and is still used now, but even that I wouldn't absolutely count on. And remember, I'm just talking about internal iframe URLs that are never publicly exposed. You'd have to be digging around in DevTools to see them anyway, so this is only relevant for you deep internals hackers anyway 😉
Another thing to be aware of is our no-referrer policy for rendering iframes. These internal URLs are meant to only be rendered inside iframes and by codepen.io itself (otherwise it's a security issue), so we require the request for these URLs to include a referrer. If not, you'll see an error page. We've seen a bit of a rise in people seeing this error. Some are legit (you need to send a referrer, no exceptions). But some are a little trickier to sort out. If you're seeing this particular error, and you think it's a mistake, hit us up in support.
If you ever use the CodePen Pen Editor from a device with a fairly small screen (generally smaller than tablet), you'll notice some big changes to the editor!
Left: old editor. Right: new editor.
Well, perhaps at first glance you don't see a dramatic change. But poking around a little, we think you'll find the mobile editor a lot more capable.
You can now add a Pen to a Collection, or even create a brand new Collection and add it immediately.
You have access to the console.
It's not as powerful as the DevTools console on a desktop browser, but, it's:
Always in the right context.
Shareable with the console open, for demonstrating non-visual JavaScript output.
Your syntax highlighting theme will be respected.
And if it's a light theme, the general editor UI goes light.
You can comment directly from the Editor.
Share to Twitter, Facebook, and DEV
One click and you'll pop over to the major social networks to share what you're looking at.
You can switch between your unprocessed and processed code, if you're using a preprocessor.
You can tidy your code.
You can analyze your code.
You have proper links to all the views that are relevant to your Pen.
Which means you can get to things like Debug View, and a proper Collab Mode and Professor Mode, which was harder to get to before. Plus direct code links, should you need them.
You can delete the Pen.
You couldn't do this from small screens before. You never know when you might need to nuke something!
The trick is, get this, responsive design.
Most of CodePen is responsive already, of course, like most other websites these days. But before now, we had a special mobile-only view for the Pen Editor. It had its own unique UI with its own special set of resources. The main problem with that, to be perfectly honest, is the technical debt of it all. Whenever we tinkered with the code of the main Pen Editor, we had a bad habit of forgetting the Mobile Editor. Our fault, of course, but that's how technical debt manifests sometimes.
So by taking the time to make the normal Pen Editor responsive, we got to bring this slew of features along with it while removing a ton of code from the ol' codebase. Hopefully a nice win-win.
