That's what we call our new system for rendering Pens in the Editor. It is a server-side system in which the <iframe> that previews your code has a real src URL which serves up your code. This is different from the client-side system we used before in which we wrote directly into the iframe with JavaScript. Turns out there are tons of advantages to doing it this way, and seemingly no disadvantages.

Here's a bunch of things that work better now.

Typekit

With Typekit, you need to specify which domains are allowed to use the fonts in a particular Kit in the Kit Settings. Now, just allow s.codepen.io and the fonts will work as exptected every time:

Typekit

It was a bit tricky before because Typekit always did work in the non-Editor / non-Live views, then if you went back to the Editor sometimes browser cache or other voodoo would allow the fonts to work. That was a quirk, this is for real.

See example of Typekit working in the Editor.

Google APIS (Maps, YouTube, etc)

We had to do a bit of funky security stuff client-side before, which we can now do server-side more easily. It was our fault, but the way were doing it kinda busted a number of Google API's, meaning even doing something simple like loading up a dynamic Google Map and plopping a pin down on it didn't work. It works fine now!

See example of Google Maps API working in the Editor.

Anything that needs proper referrer / headers

The old way, if you requested a third-party resource of any kind, the headers that third party would get were blank. Literally blank, nothing at all. Some third-parties didn't like that and either wouldn't serve the resource or would do something else weird. With Boomerang, and how the iframes are just a regular ol' URL on the internet now, proper headers (including referrer) are sent.

Scrolling in the Mobile Editor and Live View

In the Editor and Live View, we actually used double nested iframes to do the live updating before. That was fine on desktop browsers, but it completely killed the ability to scroll on (most) mobile devices. Double nested iframes are gone now, and scrolling works great.

mobile-scrolling

As a little extra-nerdy aside, apparently it's hard to control <iframe> height in iOS in some situations. They often just become the height of the document inside them, regardless of how forcefully you try to set the height (inline, CSS !important, whatever). Fortunately you can just wrap it in another container element with a set height and scroll that one.

window.innerHeight / window.innerWidth always correct

This was a weird quirk in the WebKit / Blink browsers. Part of writing into the iframe meant for just a split second, those numbers would report incorrectly. Sometimes 150 (default iframe height), more often 0. This doesn't matter anymore, meaning if you want to create a full screen element (often <canvas>) you can do that without any trickery or waiting.

var can = document.getElementById("my-canvas");

can.style.width = window.innerWidth + "px";
can.style.height = window.innerHeight + "px";

Live View on IE 7+

We had a long-standing hard-to-root-out bug in IE 7 and IE 8 that prevented Live View from working well on those browsers. That's fixed now. Still no IE 6 unfortunately. You can test in IE 6 in Full Page View though.

live-view-ie7

Firefox #hash Links

Clicking an anchor link with a #hash href would completely white out the preview before. With the real source document, it doesn't do that anymore. That's useful for traditional jump-links, mocking out things where you don't know or care what the final URL will be, and for using CSS :target tricks.

Passing ?get= and #hashes in the URL to the preview

We had a number of people wish (and sometimes assume) they could put a GET param or #hash in the URL and the preview would be able to access that like you could on a normal non-iframed page. We made this work now, while taking care of XSS concerns, so feel free to use those in Pens if needed.

See this link for an example.

Debugging Depth

When we had double iframes, it was sometimes a little unclear which Console frame was the correct one for running JavaScript. Unfortunately we still can't auto-switch the frame for you, but there is only one other choice now and it's named "CodePen".

CodePen-frame

Minor Issues

Little things that would come up from time to time for certain folks:

  • Infinite Footers issue where somehow the /full/ footer would keep duplicating and fill the page. Often when referrers were suppressed from their end.
  • White page issue where the preview in the Editor didn't load when first opening the Pen.
  • Too short issue where preview on Android didn't fill page vertically.
  • Falling down issue where on some mobile devices the preview would (bizarrely) start "falling" down off the viewable area.

All of which are fixed.


There might be even more things this fixed. It was rather astonishing going through our bug list and finding things that this change inherently fixed.

Speed-wise, it seems about the same. We worried about this at first but I think we've gotten it to the point where it is the same or faster. When using preprocessors or Pens as Resources, we had to make a server round trip anyway. And with the increased reliability, it feels better as well.

Enjoy! Let us know if you find any quirks or anything.