The Web Dev Notes Blog Presents:

Protecting Against Link Rot While Embracing the Future

Article Continues Below

In this week’s issue of Web Dev Notes, Val Head wrote about animations and how they can improve user experience. Val provided some demos, and we had to decide how to feature them.

We prefer to host demos on our own servers, a practice that guards against link rot. Link rot occurs when a site re-organizes their URL scheme but doesn’t re-direct visitors from old URLs to new ones, or when a site ceases to exist (Dean Allen where are you), or when pages are simply taken down (for reasons passing understanding).

In this case Val provided her demos via CodePen, one of the better code-sharing tools available. CodePen makes it easy to download the shared files, but it seemed a shame to host the demos locally and not take advantage of the features CodePen offers. So, cool, let’s embed the pen, right?

But wait

If we’re thinking about the future (or more helpfully, the past), we have to consider: What happens when CodePen goes away? Or changes its URL structure? Or puts limits on the number of times a pen can be viewed? None of these things seem likely today, but on a long enough timeline the survival rate for everything drops to zero (and we’ve seen a lot of link rot since 1998).

We’re conflicted between wanting fun (and helpful) toys, and being good caretakers of content; it’s something of an existential crisis.

Fortunately

There’s an answer.

My own knee-jerk argument was that updating broken demos wouldn’t be an onerous task; as long as we’re careful to save demos locally we can easily swap them in. But if we’re anticipating a future where embedded pens aren’t working, who’s to say I’ll be around and will have passed on the knowledge on how to fix them?

If cool URLs don’t change, cool content anticipates un-cool URLs.

Here’s what to do

1. Save the code locally

We have a space on our server where all demos live. (That it happens to be in the folder that’s distributed to our CDN is a bonus.)

2. Alter the embed code

Here’s the standard embed code for a pen:

<p data-height="268" data-theme-id="0" data-slug-hash="HLikb" data-default-tab="result" class='codepen'>See the Pen <a href='http://codepen.io/valhead/pen/HLikb'>Show/Hide Example</a> by Val Head (<a href='http://codepen.io/valhead'>@valhead</a>) on <a href='http://codepen.io'>CodePen</a>.</p>
<script async src="//codepen.io/assets/embed/ei.js"></script>

CodePen’s embed code, like Twitter’s and like our own embeddable comments, includes a snippet of HTML meant for when the embed script fails and the embedded content doesn’t render. This could happen for a couple reasons:

  1. JavaScript is failing, or turned off, in which case the reader probably isn’t going to benefit from CodePen’s features anyway, or
  2. CodePen’s servers aren’t responding, and the embed code isn’t going to work at all.

So, let’s change the embed code to take advantage of this built-in fail-safe and use it to make our content future friendly:

<p data-height="268" data-theme-id="0" data-slug-hash="HLikb" data-default-tab="result" class='codepen'>See the demo: <a href='http://vpsbm.com/d/390/ui-animation-and-ux-a-not-so-secret-friendship/demo-show-hide'>Show/hide example</a></p>
<script async src="//codepen.io/assets/embed/ei.js"></script>

And it works

Turn off JavaScript and re-visit Val’s article. Instead of the embedded demos you’ll see some nice-looking links.

(It’s worth noting that while I’m not necessarily endorsing CodePen over other embeddable code-sharing tools (Gists, jsFiddle, etc.) I am recommending it as a future-friendly tool for the simple reason that it has the HTML fallback snippet. Embeds that don’t have a fallback can fail invisibly, leaving holes that may or may not be evident.)

So, if CodePen goes away? The embedded demos automatically become links to our local versions. It’s a bit more work, but 100% worth it.

Web Dev Notes Proxy © 2026 | Powered by Cloudflare Worker

No Comments

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA

Designed for a Dead Language

Every language app in your pocket inherited a teaching method built for Latin. Understanding why that happened is a more useful design lesson than anything the apps themselves can teach you.
Web Dev Notes Proxy © 2026 | Powered by Cloudflare Worker

Good designers, bad websites: a proposal

Designers are good people. Some designs exclude people anyway. Alan Dalton offers a practical fix: accessibility personas that help you recognize problems while you're designing, not after. Homework included.
Web Dev Notes Proxy © 2026 | Powered by Cloudflare Worker

Design for Amiability: Lessons from Vienna

Computing was born in a Viennese café. Between 1928 and 1934, while Hitler plotted and Europe crumbled, a motley crew of mathematicians, philosophers, architects, and economists gathered weekly to puzzle out the limits of reason—and invented Computer Science in the process. What made their collaboration possible wasn't just brilliance (though they had plenty). It was amiability: the careful design of a social space where difficult people could disagree without destroying each other. Longtime Web Dev Notes contributing author Mark Bernstein mines this forgotten history for lessons that might just save today's embattled web from its worst impulses. Spoiler: it involves better coffee service and the looming threat of public humiliation.
Web Dev Notes Proxy © 2026 | Powered by Cloudflare Worker

Design Dialects: Breaking the Rules, Not the System

Design systems aren't component libraries—they’re living languages. Rigid adherence to visual rules creates brittle systems that break under contextual pressure. Fluent systems bend without breaking.
Web Dev Notes Proxy © 2026 | Powered by Cloudflare Worker

Discover more from Web Dev Notes

Subscribe now to keep reading and get access to the full archive.

Continue reading