Coincidental progressive enhancement

An escalator can never break: it can only become stairs.

You should never see an Escalator Temporarily Out Of Order sign, just Escalator Temporarily Stairs.

Sorry for the convenience.

Mitch Hedberg

Progressive enhancement is not a new style;
A tried and true method that's been here a while.
You'll see that your site would be easy to build;
The site users happy, your mission fulfilled.

Sometimes, I make decisions because I am well aware of what I am doing; sometimes, my decisions are completely arbitrary. (Or are they? 🤔)

In this blog post, I would like to discuss progressive enhancement and how I've accidentally chosen to implement it.

What is progressive enhancement?

Progressive enhancement, according to Wikiwand, is a strategy in web design that puts emphasis on web content first, allowing everyone to access the basic content and functionality of a web page, while users with additional browser features or faster Internet access receive the enhanced version instead.

Basically, it means you build websites from the ground up, starting from your content, then the HTML code, the CSS code, and the JS code, as illustrated:

It is important to remember that all websites work by default if proper (even if not perfect) HTML is used alone; CSS and JavaScript tend to break website behavior the most. In other words, all websites are responsive by default; your CSS and JavaScript code break things.

Progressive enhancement reduces the chances of you breaking your own site by starting you off from the bottom and working your way up.

In progressive enhancement, you think of the user first. You ask questions like:

• What if images don’t load?
• What if stylesheets don't load?
• What if web fonts don’t render?
• What if JavaScript fails?
• What if a 3rd party resource blocks rendering?

Some articles have even described progressive enhancement as technical credit (the opposite of technical debt).

Technical Credit is the investment in the engineering, designing and constructing of software or systems over and above the minimum necessary effort, in anticipation of emergent properties paying dividends at a later date.

I've been doing it this whole time

Ever since I have had a rekindled interest in the web in 2020, I have been coding all my websites from scratch using this strategy. Of course, I never knew that it was called progressive enhancement, and it wasn't really a strategy for me. I just did it that way because I wanted to cut out all the bloat. At the time, I was watching a lot of Luke Smite videos on YouTube and he's all about software minimalism and doing things yourself. I'll probably speak more about this in a future blog post.

I realized that I had been practicing the strategy when I read the introduction of the Wikiwand article:

[In progressive enhancement,] the web content is created with a markup document, geared towards the lowest common denominator of browser software functionality.

If content should be revealed interactively through JavaScript, such as a collapsible navigation menu, this would be by default and only first hidden by JavaScript itself.

The developer adds all desired functionality to the presentation and behavior of the page, using modern CSS, Scalable Vector Graphics (SVG), or JavaScript.

To me, progressive enhancement is about:

• Making sure your website works without CSS and JavaScript because the love of them is the root of all evil on the web. (Yes, the equivalent of the love of money in the Bible.)
• Making sure your website is accessible to all users, including users with impairments of any sort.
• Making updates to your website little by little. You don't have to get it all right the first time.
• Following web standards.

The tension

Progressive enhancement is not always easy; it involves resolving the dilemma between design and compatibility. You have to make the best choice for the users of your site so that everybody has the same experience.

There is also the tension of bare metal and abstraction; should I use a framework or not? Is Wordpress cool? What about Wix?

My advice is to stay away from those technologies.

From my experience, frameworks and CMS's generate a lot of bloat. They would always generate more code then handcrafted sites. This is the best courtesy you could pay to your users.

There are also bad fits for creating frontends for the web. The dev tools in browsers these days are powerful enough to do any type of troubleshooting you need and come with a lot of benefits right out the box. I should probably do a blog post about this as well. (I'll add it to the never-ending pile of blog post todos.)

That being said, if you've tried it, and it's too hard, I'll say what I always say: use whatever you can use. The web is all about meeting us at our various levels so we can grow. Just be aware of the HTML, CSS and JavaScript generated by these tools (of bloat). These languages directly influence the speed of your page and the viewership of site audience, since all code written is downloaded to the browser before it can be run. The more the code to parse by the browser, the longer the parsing takes.

Core principles of progressive enhancement

They include:

• Basic content should be accessible to all web browsers.
• Basic functionality should be accessible to all web browsers.
• Sparse, semantic markup contains all content.
• Enhanced layout is provided by externally linked CSS.
• Enhanced behavior is provided by externally linked JavaScript.
• End-user web browser preferences are respected.

The Still Breathing blog post I read summarizes the principles as:

1. Identify the core functionality.
2. Implement it using the simplest technology possible.
3. Enhance!

This also breaks down to:

• Use standard HTML elements; let buttons be buttons and links be links.
• Don’t rely on JavaScript (or even CSS) to deliver the core content and functionality of the page.
• Make the raw HTML usable even if everything else fails; which means you may well need to develop server-side handling of form submission.
• Check for support of features before attempting to use them.

You should think of these points as more of a philosophy than a checklist.

Benefits of progressive enhancement

• Accessibility, compatibility, and outreach: Everyone benefits; a win-win for all.
• Speed and efficiency: Less bloat generated when writing code by hand and therefore faster loading in browsers since there is less to download.
• User control: The user has more control of how the page is rendered; he can turn off JavaScript in his browser or easily modify or choose a stylesheet if all code is put in its proper place.
• Search engine optimization (SEO): It is really easy to optimize your code for search engines, like by using structured data. Great for businesses that need exposure.
• Resilience against failure: HTML without CSS and JavaScript is very resilient against errors; you could make mistakes in your markup and everything would still be rendered just fine. If the site works without CSS and JavaScript, there is a higher chance that it would work when both are present.

Bottom line

Remember, UX before infrastructure. When you enhance your websites progressively, you leave room for your user to benefit in the worse conditions and for the websites themselves to gradually grow into the responsible adults you've been training them to be (as proud webpage parents).

Further reading

• Progressive enhancement benefits
• The Problem with <div> soup in React