I love this little markup pattern: simple, accessible and elegant …with some quirky CSS gotchas around styling non-standard prefixed pseudo-elements. They came from the Shadow DOM …dun dun DUN!
A great description of a solid architectural approach to building on the web (and not just for accessibility either).
A larger screen is now a progressive enhancement. Hell, with things like Siri and Google Now and Amazon’s Echo, we’re getting to the point where even a screen is an enhancement.
A response to a rant I linked to recently.
I couldn’t agree more. The tools have evolved and we now have frameworks and practices that allow us to render from the server and use the same code to render on the client, progressively enhancing from a solid robust base.
The problem is that I don’t see a willingness from developers to embrace this way of thinking. Instead I see it dismissed as being unrealistic or more expensive.
Still, it always takes time for behaviour to change so maybe things will only get better. I certainly hope so.
This a magnificent piece of writing from James …all about pieces of metal fabric.
A single technology – the vacuum-deposition of metal vapour onto a thin film substrate – makes its consecutive and multiple appearances at times of stress and trial: at the dawn of the space age, in orbit and on other planets, at the scene of athletic feats of endurance, in defence and offence in the mountains of the Hindu Kush, on the beaches of the European archipelago. These are moments of hope as well as failure; moments when, properly utilised, technological progress enables us to achieve something which was beyond our capabilities before. And yet: we are still pulling bodies from the water wrapped in material which was meant to send us into space.
A great piece by Christian on taking a responsible, customer-focused approach to building on the web.
You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button.
A linkbaity title for a ranty post. But it’s justified.
My point is that from an architectural perspective, most single page apps are the result of making the wrong choices and missing important opportunities.
It’s okay to feel stress in response to this rapid development. It’s natural. I hate change, I hate it so so much. I like things to be consistent and for it to have it’s own place. If it doesn’t, I get stressed and my obsessive compulsive tendencies run riot in a desperate attempt to preserve order. This both benefits and hinders my work.
Chimes very nicely with the latest episode of Ctrl+Click Cast.
I think that “Do we want to support users without JS?” is the wrong question. Progressive enhancement has benefits that reach far beyond that user group.
- Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
- Business, Business, Business.
Matthew describes a very nice bit of progressive enhancement for drag’n’drop file uploads (similar to the CSS Tricks article I linked to recently).
It uses the Dropzone JS which looks like it aligns nicely with the progressive enhancement approach.
A hands-on look at building a progressive web app with Service Workers, manifest files, HTTPS, and all that good stuff. This is nice and balanced, extolling the virtues but also warning about the potential difficulties in implementing this stuff.
One nitpick though: there’s talk of graceful degradation, and while I get that that’s the outcome, I think it’s better to think in terms of progressive enhancement, which is the approach.
Ethan demonstrates progressive enhancement at the pattern level using flexbox.
I’ve found that thinking about my design as existing in broad experience tiers – in layers – is one of the best ways of designing for the modern web.
Two sides of a debate on progressive enhancement…
Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:
Joe Hoyle disagrees:
Caspar acknowledges this:
I don’t have any problem buying into pragmatism as the main and often pressing reason for not investing into a no-JS fallback. The idealistic nature of a design directive like progressive enhancement is very clear to me, and so are typical restrictions in client projects (budgets, deadlines, processes of decision making).
But concludes that by itself that’s not enough reason to ditch such a fundamental technique for building a universal, accessible web:
Ain’t nobody got time for progressive enhancement always, maybe. But entirely ditching principle as a compass for resilient decision making won’t do.
It would be convenient to think that because we live in a world where people’s browsers are regularly updating, that we live in a world where the web is in a reliable state.
The web is a continually moving target. It probably changed in the time it took me to write this. If you work with web stuff you need to embrace this fact. It will be the only constant in your career.
Do not panic:
On the web progressive enhancement is and will always be, the methodology of choice. It makes your site robust to the shifting sands of the web front end.
I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:
- The next time a user clicks, rather than being sent to the server, the client-side app is in control.
Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:
A rousing call to arms for progressive enhancement. I agree with the sentiment, but I’m less comfortable making assumptions about the reasons why developers don’t use progressive enhancement:
However, what’s actually happening is that “universal access to content” is being subversively replaced with “universal access for a limited subset of users that I care about”.
I particularly like the point in here about content blockers like NoScript:
In fact, it’s probably more likely that a user will try browsing the Web today without scripting than at any other time since the 1990s.
A fascinating ten-year old essay looking at the early days of the web and how it conquered FTP and Gopher.
And though glitz, politics, hard work, and competitors’ mistakes all played a role in the success of the web, there are also aspects of the architecture that ensured the web would catch on. I think the web won because of the URI.
URIs are everywhere, and what’s vaguely funny now is the idea that they’re something special. But they’re very special: URI management is the fundamental consideration behind the design of web sites, web applications, and web services. Tim Berners-Lee originally intended URIs to be invisible, but they’re too useful for that.
This is a terrific example of progressive enhancement in action: going from a simple file input to a lovely interactive drag’n’drop interface.
Apple offers its users the power to turn off much of the Web: fonts, styles, scripts, and more.
He rightly points out that the answer to building a robust, resilient web has been here all along:
Bruce gives a great run-down of what’s involved in creating one of those new-fangled progressive apps that everyone at Google and Opera (and soon, Mozilla) are talking about: a secure connection, a service worker, and a manifest file.
Crucially, in browsers that don’t support it, you have a normal website. It’s perfect progressive enhancement.
Funnily enough, this here website—adactio.com—is technically a progressive app now.
At their simplest, Progressive Web Apps are application-like things hosted on your web server. If you’re as old as me, you might call them “web sites”
Outlining the architectural thinking required to create what the Google devrel folks are calling progressive apps.
Browsers without service worker support should always be served a fall-back experience. In our demo, we fall back to basic static server-side rendering…
…but this is only one of many options.
Hmmm. In my opinion, sending usable HTML on first request isn’t an implementation detail—it’s crucial. But on the whole, this approach is very sensible indeed.
Paul gives the lowdown on the Google+ responsive relaunch. They set themselves this performance budget:
- 60K of HTML,
- 60K of CSS,
- 60 frames per second animations, and
- 0.6 seconds latency.
And this bit is crucial:
Are we doomed to see history repeat itself? With the amount of client-side MVC frameworks and the upcoming implementation of the ES6 syntax, will we soon be seeing a repeat of the “browser wars.” Will more websites only work in a select number of browsers with the capabilities to run their code?
The full transcript of Scott’s excellent presentation on performance and progressive enhancement.
There’s going to be a conference about progressive enhancement. It’ll happen in London in March of next year. You should speak at it.
You’ve got until December 20th to submit your proposal. What have you got to lose?
It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:
Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.
Here’s the 20 minute talk I gave at the inaugural Responsive Field Day in Portland.
Websites should not come with minimum software requirements.
Here’s the video of the talk I gave at An Event Apart last year.
Guess what it’s about. Go on, guess!
No! It’s about progressive enha… oh.
Aaron collects some recent examples that demonstrate
- why we should use HTTPS and
- why we should use progressive enhancement.
The video of my talk at this year’s Beyond Tellerrand. I was pleased with how this went, except for the bit 16 minutes in when I suddenly lost the ability to speak.
What a lovely bit of progressive enhancement—styling data tables to display as charts.
A wonderful collection of treasures excavated from GeoCities. Explore, enjoy, and remember what a crime it is that Yahoo wiped out so much creativity and expression.
This was a fun way to spend the day—getting my hands dirty with ink and type.
Here’s the video of the panel I participated in at Edge conference, expertly moderated by Lyza.
Thanks to the video editing, you can’t see the face I’m making when the guy from Facebook talks about user-agent sniffing as a totally cool and reliable way of working.
The full text of Jason’s great talk at this year’s CSS Summit. It’s a great read, clearing up many of the misunderstandings around progressive enhancement and showing some practical examples of progressive enhancement working at each level of the web’s technology stack
Many believe we should leave the term “progressive enhancement” behind and start anew, but why not educate developers, clients and stakeholders and change many of the misconceptions surrounding it? Changing the name won’t change anything unless we address the real fundamental problems we have when describing the underlying concepts.
A superb illustration of why playing the numbers game and dismissing even a small percentage of your potential audience could be disastrous.
This is the way to approach building for the web:
I want to make as few of those assumptions as possible. Because every assumption I make introduces fragility. Every assumption introduces another way that my site can break.
It’s progressive enhancement, but like Stuart, Tim is no longer planning to use that term.
Stuart writes up his thoughts on progressive enhancement following the great discussions at Edge Conf:
So I’m not going to be talking about progressive enhancement any more. I’m going to be talking about availability. About reach. About my web apps being for everyone even when the universe tries to stop it.
I really like Alex’s framing of best-of-breed progressively enhanced websites as “progressive apps” (although Bruce has some other ideas about the naming).
It’s a shame that the add-to-homescreen part isn’t standardised yet though.
This sounds like it could be a very useful tool to introduce early in projects to get a shared understanding of progressive enhancement.
Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.
The system makes the website. Don’t blame the web developer, blame the organisation. A web developer embedded in a large system isn’t the one making the websites.
To make a progressively enhanced website that performs well and loads quickly even on slow connections, you need to first make an organisation that values those qualities over others.
This is a great blow-by-blow account of making an agency website perform better.
I love the side-by-side comparisons with other agencies, including Clearleft—the gauntlet has been thrown down!
Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.
This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).
Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.
Websites can be viewed by anyone with a web browser.
And that doesn’t mean foregoing modern features:
A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.
This is why progressive enhancement is so powerful.
My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.
This is a wonderful presentation by Kimberley at O’Reilly’s Fluent Conference, running through the history of the Line Mode Browser and the hack project we worked on at CERN to emulate it.
And that’s why you always use progressive enhancement!
I like this nice straightforward approach. Instead of jumping into the complexities of the final interactive component, Chris starts with the basics and layers on the complexity one step at a time, thereby creating a more robust solution.
If I had one small change to suggest, maybe
aria-label might work better than offscreen text for the controls …as documented by Heydon.
A superb piece by Ross Penman on the importance of being true to the spirit of the web.
The responsive BBC News site is live! Hurrah!
Here’s a look at the highs and lows of the site’s story, emphasising the importance of progressive enhancement and all that enables: feature detection (by “cutting the mustard”), conditional loading, and a mobile-first approach.
Jeffrey muses on progressive enhancement and future-friendliness.
Because in 10 years nothing you built today that depends on JS for the content will be available, visible, or archived anywhere on the web.
It will come as no surprise that I agree with every single word that Tim has written here.
The minimum dependency for a web site should be an internet connection and the ability to parse HTML.
A great description of progressive enhancement.
Progressive enhancement in its basic form means not making assumptions
Smart thinking from Sara on providing a PNG fallback to browsers that don’t support SVG. Although, actually what I like about this solution is that it’s less about providing PNG as a fallback, and more about treating PNG as the baseline and SVG as the enhancement (an approach that the picture element is perfect for).
A nice little pattern for generating a swish timeline in SVG from a plain ol’ definition list in HTML.
You know what? Just go and read everything that Jason writes, okay?
Ruddy good stuff.
The engineering benefits of building websites with a layered approach.
Why, yes, I am talking about progressive enhancement yet again! Why do you ask?
Tom doesn’t mention the phrase “progressive enhancement” once, but that’s okay—his post is still about progressive enhancement.
FastBoot is coming to Ember. That means server-side rendering. And that means progressive enhancement will become a possibility for Ember apps. Exciting!
I really enjoyed chatting with the guys on the The Dirt podcast about progressive enhancement, but my goodness; it certainly sounds like I need to switch to decaf! Yappity-yapity-yap!
This is a talk I gave at An Event Apart about eighteen months ago, all about irish music, the web, long-term thinking, and yes, you guessed it—progressive enhancement.
Rob Larsen was published a book with O’Reilly called “The Uncertain Web: Web Development in a Changing Landscape”. I like it:
A refreshingly honest look at the chaotic, wonderful world of web development, with handy, practical advice for making future-friendly, backward-compatible websites.
I’m not a new developer, but I can definitely relate to this. In fact, when I’ve spoken to any developer about this, it turns out that everyone feels overwhelmed by how much we’re expected to know. That’s not good. We should open up and talk about this more (like Charlotte is doing here).
You can now read Aaron’s excellent book online. I highly recommend reading the first chapter for one of the best descriptions of progressive enhancement that I’ve ever read.
Watch this space.
My contribution to this year’s edition of the web’s best advent calendar.
A superb article by Josh on planning for progressive enhancement—clearly laid out and carefully explained.
Focus on what you want to learn; not what you think you should learn.
There is a lot of pressure out there: to learn new things, to spend all your time coding, to be the super developer. I now believe that to be impossible and unhealthy. It means you aren’t living a balanced life and it also means that you’re living under constant stress and pressure.
Angry, but true.
Don’t lock yourself into a comprehensive technology that may just die within the next few months and leave you stranded. With progressive enhancement you’ll never go wrong. Progressive enhancement means your code will always work, because you’ll always focus on providing a minimal experience first, and then adding features, functionality, and behavior on top of the content.
Tantek shares a fascinating history lesson from Tim Berners-Lee on how the IETF had him change his original nomenclature of UDI—Universal Document Identifier—to what we now use today: URL—Uniform Resource Locator.
I don’t tend to be a “magic pill” kind of believer, but I can honestly say that embracing progressive enhancement can radically change your business for the better. And I’m glad to see Google agrees with me.
Google has updated its advice to people making websites, who might want to have those sites indexed by Google. There are two simple bits of advice: optimise for performance, and use progressive enhancement.
Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
Petra has always been the strong one. She was the best friend that Chloe could have possibly had. Little wonder then that Chloe’s death continues to hit her so hard.
I still can’t fully comprehend it all nor do I have any idea how to learn to move on. All I know is that ever since the day I found out, I’ve been on an emotional rollercoaster. I go from being in shock, to being sad and angry, or completely numb.
Petra is getting help now. That’s good. She’s also writing about what she has been going through. That’s brave. Very brave.
She is one of the best human beings I know.
Patty Toland — Design Consistency For The Responsive Web (Smashing Conference Freiburg 2014) on Vimeo
Patty’s excellent talk on responsive design and progressive enhancement. Stick around for question-and-answer session at the end, wherein I attempt to play hardball, but actually can’t conceal my admiration and the fact that I agree with every single word she said.
Some thoughts on progressive enhancement, although I disagree with the characterisation of progressive enhancement as being the opposite choice to making “something flashy that pushes the web to it’s limits”—it’s entirely possible to make the flashiest, limit-pushing sites using progressive enhancement. After all…
it’s much more a mindset than a particular development technique.
It’s very early days for ServiceWorker, but Jake is on hand with documentation and instructions on its use. To be honest, most of this is over my head and I suspect it won’t really “click” until I try using it for myself.
Where it gets really interesting is in the comments. Stuart asks “What about progressive enhancement?” And Jake points out that because a ServiceWorker won’t be installed on a first visit, you pretty much have to treat it as an enhancement. In fact, you’d have to go out of your way to make it a requirement:
You could, of course, throw up a splash screen and wait for the ServiceWorker to install, creating a ServiceWorker-dependant experience. I will hunt those people down.
I very much agree with Orde’s framing here: I don’t think it makes much sense to talk about “above the fold” CSS …but it makes a lot of sense to talk about critical CSS.
And, yeah, it’s another example of progressive enhancement.
I’m sad about Robin Williams. I was also a little bit angry with him. In much the same way, I was sad about and angry with Chloe Weil when news of her suicide reached me.
Dan Donald gets to the heart of progressive enhancement:
Assumptions in themselves don’t have to be inherently bad but let’s recognise them for what they are. We know very little but that can hopefully enable us to be far more flexible and understanding in what we create.
Almost six minutes of me squinting in the sun and sharing my reckons while seagulls squawk in the background.
I really hope that this is the kind of usage we’ll see for web components: enhancements for the browsers that support them without a good ol’ fashioned fallback for older browsers.
Right now, this move to remove URLs from the interface of Chrome is just an experiment …but the fact that Google are even experimenting with it is very disturbing.
“Who? Me? No, I was never going to actually blow the web’s brains out—I just wanted to feel the heft of the weapon as I stroked it against the face of the web.”