So what is the one thing that people can do is to make their website better? To answer that, let’s take a step back in time …
The year is 1998, and the web is on the rise. In an attempt to give a high-level overview of the architecture of the WWW, Tim Berners-Lee — yes, that Tim Berners-Lee — publishes a paper called “Web Architecture from 50,000 feet”. The report covers lots of things: content negotiation, the semantic web, HTML, CSS, and cool URIs (which don’t change), among others.
The Rule of Least Power goes like this:
When designing computer systems, one is often faced with a choice between using a more or less powerful language for publishing information, for expressing constraints, or for solving some problem. […] The “Rule of Least Power” suggests choosing the least powerful language suitable for a given purpose.
We have three main languages available on the web for the front end:
Semantically describes the content
Controls the presentation and layout
Adds interactivity and behavior
As Derek Featherstone nicely put it:
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
💡 Hold up: This doesn’t mean you should set font sizes and colors via markup — a thing we used to do in the “olden” days of the web. Case in point: one of the rules covered in Berners-Lee’s piece is the separation of form and content.
The broken web
It has been almost 25 years since Berners-Lee published that article. Yet, somehow, the message he sent didn’t get through, and many developers — but not all — are unaware of it. Take this situation Drew Devault encountered not so long ago:
While a form might be a familiar example, there are more situations where applying the Rule of Least Power gives better results:
👉 A <form> element with [method=”dialog”] will do just fine.Want to lazy load images?
👉 That will soon be supported by all modern browsers directly in HTML markup with an attribute.A customizable <select>?
👉 That’s in development as we speak.Want to link animations to a scroll-offset?
👉 Don’t disable pasting but instead choose a proper input type and/or use the pattern attribute.Need collapsing sections?
👉 <details> and <summary> are your friends.and so on…
In all these examples, we can move some functionality from an upper into a lower layer. Berners-Lee would be proud of us.
By choosing a technology lower in the web stack, closer to the core of the web platform, we also gain the benefit of built-in resilience against failures.
CSS, on the other hand, is very good at failing. Even if you have a syntax error in one of your style sheets, the rest of your CSS will still work. Same with HTML. These are forgiving languages.
If you doubt why you should use the Rule of Least Power, Jeremy Keith brings us the answer in his article “Evaluating Technology”:
We tend to ask “How well does it work?”, but what you should really be asking is “How well does it fail?”
We can do better
The same goes for certain CSS features that may or may not be available. Provide basic styling, and when a feature is available — detectable using @supports — enhance the result you already had.
This approach is known as progressive enhancement: You add functionality as more features become available, making the result better as far as the experience goes, but not so much that the feature cannot work without those extra flourishes.
And for browsers that don’t yet support a particular new feature, you can try and find a polyfill that provides that functionality to the browsers.
The web catches up
Things that were impossible years ago and that could only be done by relying on external technologies, like Flash, are now built into the browser itself.
A classic example is the features jQuery introduced. Over ten years ago, jQuery was the very first thing to drop into a project. Today, that’s no longer the case, as the web platform has caught up and now has document.querySelectorAll(), Element.classList, etc. built-in — all features inspired upon features jQuery gave us. You could say that jQuery was a polyfill before polyfills even were called polyfills.
While jQuery might be a familiar example, there are many other situations where the web has caught up:
👉 Why not give the built-in Web Animations API a try? It’s really powerful.Need colored radio buttons and checkboxes?
👉 The new CSS accent-color property does that for you.Relying on a preprocessor so that you can use CSS variables?
👉 CSS Custom Properties are the single greatest addition to CSS over the past 20 years.and so on…
The central theme here is that these features no longer rely on a polyfill or an external library but have shifted closer to the core of the web stack. The web catches up.
While some of these new APIs can be pretty abstract, there are libraries out there that you can plug into your code. An example is Redaxios, which uses fetch under the hood while also exposing a developer-friendly, Axios-compatible API. It wouldn’t surprise me if these convenience methods eventually trickle down into the web platform.
What Berners-Lee wrote almost 25 years ago stands the test of time. It’s up to us, developers, to honor that message. By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.
Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.