A great reminder of just how much you can do with modern markup and styles when it comes to form validation. The :user-invalid and :user-valid pseudo-classes are particularly handy!
Progressive enhancement begins with constructing a robust and universally accessible foundation, designed to cater to all users, regardless of individual or technological circumstances. From here, advanced features can be strategically layered to enhance the user experience wherever feasible. Even as these enhancements roll out, guided by the capacities of different devices, the quality of network connections, or the availability of specific APIs, the core functionalities should remain steadfast and accessible to all.
Some great ideas for view transitionts in here! Also:
If you look at any of the examples on a browser that does not support them, the pages still function just fine. The transitions are an extra that’s layered on top if and when your browser supports them. Another concrete example of progressive enhancement in practice.
I must admit, when Jake told me he was leaving Google, I got very worried about the future of the View Transitions API.
To recap: Chrome shipped support for the API, but only for single page apps. That had me worried:
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
Well, the multi-page version still hasn’t yet shipped in Chrome stable, but it is available in Chrome Canary behind a flag, so it looks like it’s almost here!
Robin took the words out of my mouth:
Anyway, even this cynical jerk is excited about this thing.
Are you the kind of person who flips feature flags on in nightly builds to test new APIs?
Me neither.
But I made an exception for the View Transitions API. So did Dave:
I think the most telling predictor for the success of the multi-page View Transitions API – compared to all other proposals and solutions that have come before it – is that I actually implemented this one. Despite animations being my bread and butter for many years, I couldn’t be arsed to even try any of the previous generation of tools.
Dave’s post is an excellent step-by-step introduction to using view transitions on your website. To recap:
Enable these two flags in Chrome Canary:
chrome://flags#view-transition
chrome://flags#view-transition-on-navigation
Then add this meta element to the head of your website:
<meta name="view-transition" content="same-origin">
You could stop there. If you navigate around your site, you’ll see that the navigations now fade in and out nicely from one page to another.
But the real power comes with transitioning page elements. Basically, you want to say “this element on this page should morph into that element on that page.” And when I say morph, I mean morph. As Dave puts it:
Behind the scenes the browser is rasterizing (read: making an image of) the before and after states of the DOM elements you’re transitioning. The browser figures out the differences between those two snapshots and tweens between them similar to Apple Keynote’s “Magic Morph” feature, the liquid metal T-1000 from Terminator 2: Judgement Day, or the 1980s cartoon series Turbo Teen.
If those references are lost on you, how about the popular kids book series Animorphs?
Some classic examples would be:
I’ve added view transitions to The Session. Where I’ve got index pages with lists of titles, each title morphs into the heading on the next page.
Again, Dave’s post was really useful here. Each transition needs a unique name, so I used Dave’s trick of naming each transition with the ID of the individual item being linked to.
In the recordings section, for example, there might be a link like this on the index page:
<a href="/recordings/7812" style="view-transition-name: recording-7812">The Banks Of The Moy</a>
Which, if you click on it, takes you to the page with this heading:
<h1><span style="view-transition-name: recording-7812">The Banks Of The Moy</span></h1>
Why the span? Well, like Dave, I noticed some weird tweening happening between block and inline elements. Dave solved the problem with width: fit-content on the block-level element. I just stuck in an extra inline element.
Anyway, the important thing is that the name of the view transition matches: recording-7812.
I also added a view transition to pages that have maps. The position of the map might change from page to page. Now there’s a nice little animation as you move from one page with a map to another page with a map.
That’s all good, but I found myself wishing that I could just have those enhancements. Every single navigation on the site was triggering a fade in and out—the default animation. I wondered if there was a way to switch off the default fading.
There is! That default animation is happening on a view transition named root. You can get rid of it with this snippet of CSS:
::view-transition-image-pair(root) {
isolation: auto;
}
::view-transition-old(root),
::view-transition-new(root) {
animation: none;
mix-blend-mode: normal;
display: block;
}
Voila! Now only the view transitions that you name yourself will get applied.
You can adjust the timing, the easing, and the animation properites of your view transitions. Personally, I was happy with the default morph.
In fact, that’s one of the things I like about this API. It’s another good example of declarative design. I say what I want to happen, but I don’t need to specify the details. I’ll let the browser figure all that out.
That’s what’s got me so excited about this API. Yes, it’s powerful. But just as important, it’s got a very low barrier to entry.
Chris has gathered a bunch of examples together in his post Early Days Examples of View Transitions. Have a look around to get some ideas.
If you like what you see, I highly encourage you to add view transitions to your website now.
“But wait,” I hear you cry, “this isn’t supported in any public-facing browser yet!”
To which, I respond “So what?” It’s a perfect example of progressive enhancement. Adding one meta element and a smidgen of CSS will do absolutely no harm to your website. And while no-one will see your lovely view transitions yet, once browsers do start shipping with support for the API, your site will automatically get better.
Your website will be enhanced. Progressively.
Update: Simon Pieters quite rightly warns against adding view transitions to live sites before the API is done:
in general, using features before they ship in a browser isn’t a great idea since it can poison the feature with legacy content that might break when the feature is enabled. This has happened several times and renames or so were needed.
Good point. I must temper my excitement with pragmatism. Let me amend my advice:
I highly encourage you to experiment with view transitions on your website now.
- Start with mostly static HTML.
- Progressively enhance the dynamic parts.
- Pick small, focused tools.
The most cartoonish misrepresentation of progressive enhancement is that it means making everything work without JavaScript.
No. Progressive enhancement means making sure your core functionality works without JavaScript.
In my book Resilient Web Design, I quoted Wilto:
Lots of cool features on the Boston Globe don’t work when JS breaks; “reading the news” is not one of them.
That’s an example where the core functionality is readily identifiable. It’s a newspaper. The core functionality is reading the news.
It isn’t always so straightforward though. A lot of services that self-identify as “apps” will claim that even their core functionality requires JavaScript.
Surely I don’t expect Gmail or Google Docs to provide core functionality without JavaScript?
In those particular cases, I actually do. I believe that a textarea in a form would do the job nicely. But I get it. That might take a lot of re-engineering.
So how about this compromise…
Your app should work in a read-only mode without JavaScript.
Without JavaScript I should still be able to read my email in Gmail, even if you don’t let me compose, reply, or organise my messages.
Without JavaScript I should still be able to view a document in Google Docs, even if you don’t let me comment or edit the document.
Even with something as interactive as Figma or Photoshop, I think I should still be able to view a design file without JavaScript.
Making this distinction between read-only mode and read/write mode could be very useful, especially at the start of a project.
Begin by creating the read-only mode that doesn’t require JavaScript. That alone will make for a solid foundation to build upon. Now you’ve built a fallback for any unexpected failures.
Now start adding the read/write functionally. You’re enhancing what’s already there. Progressively.
Heck, you might even find some opportunities to provide some read/write functionality that doesn’t require JavaScript. But if JavaScript is needed, that’s absolutely fine.
So if you’re about to build a web app and you’re pretty sure it requires JavaScript, why not pause and consider whether you can provide a read-only version.
Ahmad runs through some of the scenarios where text-wrap: balance could be handy.
Even though it’s not well-supported yet in browsers, there’s no reason not to start adding it to sites now; it’s classic progressive enhancement.
After admiring the loveliness of the homepage for Enhance, try reloading it with JavaScript switched off.
Spot the difference? Me neither.
So, if progressive enhancement is no more expensive to create, future-proof, provides us with technical credit, and ensures that our users always receive the best possible experience under any conditions, why has it fallen by the wayside?
Because before, when you clicked on a link, the browser would go white for a moment.
JavaScript frameworks broke the browser to avoid that momentary loss of control. They then had to recreate everything that the browser had provided for free: routing, history, the back button, accessibility features, the ability for search engines to read the page, et cetera iterum ad infinitum.
Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.
The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:
- You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
- In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
- Always style from the absolute smallest screen your content will be rendered on first, and use
@media (min-width)queries to break to layouts that allow for more real estate as it becomes available.- If your site doesn’t work without JavaScript, your site doesn’t work.
- Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.
It is not an exaggeration to say that modern frontend is so enamoured by post-scarcity fairy tales that it is mortgaging the web’s future for another round of night drinking at the JavaScript party.
Strong—and true—words from Alex.
This isn’t working for users or for businesses that hire developers hopped up Facebook’s latest JavaScript hopium. A correction is due.
I concur.
Frontend’s failure to deliver in today’s mostly-mobile, mostly-Android world is shocking, if only for the durability of the myths that sustain the indefensible. We can’t keep doing this.
If you disagree, I encourage you to dive into the data that Alex shares.
It sounds like Remix takes a sensible approach to progressive enhancement.
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.
I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.
The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.
I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.
Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:
The most popular architecture employed by web developers today is the Single Page App (SPA)
Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.
I realised, progressive enhancement isn’t only about supporting that 1%. It’s about testing your app without JavaScript to ensure 100% of your users have a more performant, usable, available, and resilient experience.
A really good explanation of progressive enhancement as an approach to building anything on the web:
Progressive enhancement does not mean you need to provide the exact same UI without JavaScript. The enhanced experience should be better and it should do more, otherwise the enhanced experience is not needed at all. It enhances a degraded experience that also allows the user to accomplish their goal. For example, entering a postal code manually into a text box might be the degraded experience, and the progressively enhanced experience would prefill the text box based on Geolocation data.
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
This is kind of brilliant:
Maybe what’s needed for websites and web apps is a kind of Prepper Web Dev?
Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.