- Building HTML pages is easy
- Pure HTML is evergreen
- Bloated web pages are too slow
- I can host it anywhere, often for free
- Accessibility and SEO benefits are automatic
- It won’t need security patches
- There are no build steps
SPAs were a clever solution to a temporary limitation. But that limitation no longer exists.
Use modern server rendering. Use actual pages. Animate with CSS. Preload with intent. Ship less JavaScript.
- Install Stuff Indiscriminately From npm
- Pick a Framework Before You Know You Need One
- Always, Always Require a Compilation Step
Hannah runs through the details of making a grid-aware website:
The design adjusts between “low”, “moderate”, and “high” based on the quantity of fossil fuels on your local energy grid.
I like this idea, but I really think it needs to be on by default, rather than being opt-in.
And I’m really intrigued by the idea of a grid-aware browser!
A fantastic explanation of the building blocks of SVG, illustrated—as always—with Josh’s interactive examples.
If you’re a front-end developer and you don’t read Chris Ferdinandi’s blog, you should change that right now. Add that RSS feed to your feed reader of choice!
Lately he’s been posting about some of the thinking behind his Kelp UI library. That includes some great nuggets of wisdom around HTML web components.
First of all, he pointed out that web components don’t need a constructor(). This was news to me. I thought custom elements had to include this incantation at the start:
constructor () {
super();
}
But it turns that if all you’re doing is calling super(), you can omit the whole thing and it’ll be done for you.
I immediately refactored all the web components I’m using on The Session. While I was at it, I implemented Chris’s bulletproof web component loading.
Now technically, I don’t need to do this. I’m linking to my JavaScript at the bottom of every page so I know it’s going to load after the HTML. But I don’t like having that assumption baked into my code.
For any of my custom elements that reference other elements in the DOM—using, say, document.querySelector()—I updated the connectedCallback() method to use Chris’s technique.
It turned out that there weren’t that many of my custom elements that were doing that. Because HTML web components are wrapped around existing markup, the contents of the custom element are usually what matters (rather than other elements on the same page).
I guess that’s another unexpected benefit to HTML web components. Because they’ve already got their own bit of DOM inside them, you don’t need to worry about when you load your markup and when you load your JavaScript.
And no faffing about with the dark arts of the Shadow DOM either.
I don’t normally link to articles on Medium—I respect you too much—and I do wish this were written on Mike Hall’s own site, but this is just too good not to share.
And don’t dismiss this as a nostalgiac case study from the past:
At no point did the constraints make the product feel compromised. Users on modern devices got a smooth experience and instant feedback, while those on older devices got fast, reliable functionality. Users on feature phones got the same core experience without the bells and whistles.
The constraints forced us to solve problems in ways we wouldn’t have considered otherwise. Without those constraints, we could have just thrown bytes at the problem, but with them every feature had to justify itself. Core functionality had to work everywhere, and without JavaScript crutches proper markup became essential.
This experience changed how I approach design problems. Constraints aren’t a straitjacket, keeping us from doing our best work; they are the foundation that makes innovation possible. When you have to work within severe limitations, you find elegant solutions that scale beyond those limitations.
This is a really thoughtful look at the evolution of CSS and the ever-present need to balance power with learnability.
A UI library for people who love HTML, powered by modern CSS and Web Components.
Grrr…
Chrome, Edge and Firefox updates usually reach 95% of users within three months. But Safari updates are tied to a new release of the underlying operating system, so they take around 19 months to reach the same usage, and some updates may even need a new device.
This is so shameful. And glad as I am to see new features landing in Safari, as long as they hobble updates like this it’s all just pissing in the wind.
Semantic HTML? Optional. Server-side rendering? Rebuilt from scratch. Accessibility? Maybe, if there’s time. Performance? Who cares, when you can save costs by putting loading burdens onto the user’s device, instead of your server?
So gradually, the web became something you had to compile before you could publish. Not because users needed it. But because developers wanted it to feel modern.
Everything’s optimised for developers – and hostile to everyone else.
This isn’t accidental. It’s cultural. We’ve created an industry where complexity is celebrated. Where cleverness is rewarded. Where engineering sophistication is valued more than clarity, usability, or commercial effectiveness.
Here’s what the “AI will replace developers” crowd fundamentally misunderstands: code is not an asset—it’s a liability. Every line must be maintained, debugged, secured, and eventually replaced. The real asset is the business capability that code enables.
If AI makes writing code faster and cheaper, it’s really making it easier to create liability. When you can generate liability at unprecedented speed, the ability to manage and minimize that liability strategically becomes exponentially more valuable.
This is particularly true because AI excels at local optimization but fails at global design. It can optimize individual functions but can’t determine whether a service should exist in the first place, or how it should interact with the broader system. When implementation speed increases dramatically, architectural mistakes get baked in before you realize they’re mistakes.
“We’ve stripped React out of our highest-traffic user flows and replaced it with vanilla JavaScript using small, focused libraries for specific needs,” said the CTO of a streaming service. “Our page load times dropped by 60% and our conversion rates improved by 14%.”
The joy came flooding back to me! It turns out browser APIs are really good now.
It seems like the misguided perception of needing to use complex tools and frameworks to build a website comes from a thinking that web browsers are inherently limited. When, in fact, browsers have evolved to a tremendous degree
I heard you like divs…
Why single-page apps are just not worth it:
Here’s the problem: your team almost certainly doesn’t have what it takes to out-engineer the browser. The browser will continuously improve the experience of plain HTML, at no cost to you, using a rendering engine that is orders of magnitude more efficient than JavaScript.
Meanwhile, the browser marches on, improving the UX of every website that uses basic HTML semantics. For instance: browsers often don’t repaint full pages anymore.
A great talk by Matthias on what you can do with web standards today!
Today is Global Accessibility Awareness Day:
The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.
Awareness is good. It’s necessary. But it’s not sufficient.
Accessibility, like sustainability and equality, is the kind of thing that most businesses will put at the end of sentences that begin “We are committed to…”
It’s what happens next that matters. How does that declared commitment—that awareness—turn into action?
In the worst-case scenario, an organisation might reach for an accessibility overlay. Who can blame them? They care about accessibility. They want to do something. This is something.
Good intentions alone can result in an inaccessible website. That’s why I think there’s another level of awareness that’s equally important. Designers and developers need to be aware of what they can actually do in service of accessibility.
Fortunately that’s not an onerous expectation. It doesn’t take long to grasp the importance of having good colour contrast or using the right HTML elements.
An awareness of HTML is like a superpower when it comes to accessibility. Like I wrote in the foreword to the Web Accessibility Cookbook by O’Reilly:
It’s supposed to be an accessibility cookbook but it’s also one of the best HTML tutorials you’ll ever find. Come for the accessibility recipe; stay for the deep understanding of markup.
The challenge is that HTML is hidden. Like Cassie said in the accessibility episode of The Clearleft Podcast:
You get JavaScript errors if you do that wrong and you can see if your CSS is broken, but you don’t really have that with accessibility. It’s not as obvious when you’ve got something wrong.
We are biased towards what we can see—hierarchy, layout, imagery, widgets. Those are the outputs. When it comes to accessibility, what matters is how those outputs are generated. Is that button actually a button element or is it a div? Is that heading actually an h1 or is it another div?
This isn’t about the semantics of HTML. This is about the UX of HTML:
Instead of explaining the meaning of a certain element, I show them what it does.
That’s the kind of awareness I’m talking about.
One way of gaining this awareness is to get a feel for using a screen reader.
The name is a bit of a misnomer. Reading the text on screen is the least important thing that the software does. The really important thing that a screen reader does is convey the structure of what’s on screen.
Friend of Clearleft, Jamie Knight very generously spent an hour of his time this week showing everyone the basics of using VoiceOver on a Mac (there’s a great short video by Ethan that also covers this).
Using the rotor, everyone was able to explore what’s under the hood of a web page; all the headings, the text of all the links, the different regions of the page.
That’s not going to turn anyone into an accessibility expert overnight, but it gave everyone an awareness of how much the HTML matters.
Mind you, accessibility is a much bigger field than just screen readers.
Fred recently hosted a terrific panel called Is neurodiversity the next frontier of accessibility in UX design?—well worth a watch!
One of those panelists—Craig Abbott—is speaking on day two of UX London next month. His talk has the magnificent title, Accessibility is a design problem:
I spend a bit of time covering some misconceptions about accessibility, who is responsible for it, and why it’s important that we design for it up front. It also includes real-world examples where design has impacted accessibility, before moving onto lots of practical guidance on what to be aware of and how to design for many different accessibility issues.
Get yourself a ticket and get ready for some practical accessibility awareness.
I’ve been thinking about the kind of CSS I write by default when I start a new project.
Some of it is habitual. I now use logical properties automatically. It took me a while to rewire my brain, but now seeing left or top in a style sheet looks wrong to me.
When I mentioned this recently, I had some pushback from people wondering why you’d bother using logical properites if you never planned to translate the website into a language with a different writing system. I pointed out that even if you don’t plan to translate a web page, a user may still choose to. Using logical properties helps them. From that perspective, it’s kind of like using user preference queries.
That’s something else I use by default now. If I’ve got any animations or transitions in my CSS, I wrap them in prefers-reduced-motion: no-preference query.
For instance, I’m a huge fan of view transitions and I enable them by default on every new project, but I do it like this:
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}
I’ll usually have a prefers-color-scheme query for dark mode too. This is often quite straightforward if I’m using custom properties for colours, something else I’m doing habitually. And now I’m starting to use OKLCH for those colours, even if they start as hexadecimal values.
Custom properties are something else I reach for a lot, though I try to avoid premature optimisation. Generally I wait until I spot a value I’m using more than two or three times in a stylesheet; then I convert it to a custom property.
I make full use of clamp() for text sizing. Sometimes I’ll just set a fluid width on the html element and then size everything else with ems or rems. More often, I’ll use Utopia to flow between different type scales.
Okay, those are all features of CSS—logical properties, preference queries, view transitions, custom properties, fluid type—but what about actual snippets of CSS that I re-use from project to project?
I’m not talking about a CSS reset, which usually involves zeroing out the initial values provided by the browser. I’m talking about tiny little enhancements just one level up from those user-agent styles.
Here’s one I picked up from Eric that I apply to the figcaption element:
figcaption {
max-inline-size: max-content;
margin-inline: auto;
}
That will centre-align the text until it wraps onto more than one line, at which point it’s no longer centred. Neat!
Here’s another one I start with on every project:
a:focus-visible {
outline-offset: 0.25em;
outline-width: 0.25em;
outline-color: currentColor;
}
That puts a nice chunky focus ring on links when they’re tabbed to. Personally, I like having the focus ring relative to the font size of the link but I know other people prefer to use a pixel size. You do you. Using the currentColor of the focused is usually a good starting point, thought I might end up over-riding this with a different hightlight colour.
Then there’s typography. Rich has a veritable cornucopia of starting styles you can use to improve typography in CSS.
Something I’m reaching for now is the text-wrap property with its new values of pretty and balance:
ul,ol,dl,dt,dd,p,figure,blockquote {
hanging-punctuation: first last;
text-wrap: pretty;
}
And maybe this for headings, if they’re being centred:
h1,h2,h3,h4,h5,h6 {
text-align: center;
text-wrap: balance;
}
All of these little snippets should be easily over-writable so I tend to wrap them in a :where() selector to reduce their specificity:
:where(figcaption) {
max-inline-size: max-content;
margin-inline: auto;
}
:where(a:focus-visible) {
outline-offset: 0.25em;
outline-width: 0.25em;
outline-color: currentColor;
}
:where(ul,ol,dl,dt,dd,p,figure,blockquote) {
hanging-punctuation: first last;
text-wrap: pretty;
}
But if I really want them to be easily over-writable, then the galaxy-brain move would be to put them in their own cascade layer. That’s what Manu does with his CSS boilerplate:
@layer core, third-party, components, utility;
Then I could put those snippets in the core layer, making sure they could be overwritten by the CSS in any of the other layers:
@layer core {
figcaption {
max-inline-size: max-content;
margin-inline: auto;
}
a:focus-visible {
outline-offset: 0.25em;
outline-width: 0.25em;
outline-color: currentColor;
}
ul,ol,dl,dt,dd,p,figure,blockquote {
hanging-punctuation: first last;
text-wrap: pretty;
}
}
For now I’m just using :where() but I think I should start using cascade layers.
I also want to start training myself to use the lh value (line-height) for block spacing.
And although I’m using the :has() selector, I don’t think I’ve yet trained my brain to reach for it by default.
CSS has sooooo much to offer today—I want to make sure I’m taking full advantage of it.