Tags: enhancement

Adapting to Input · An A List Apart Article

Jason breaks down the myths of inputs being tied to device form factors. Instead, given the inherent uncertainty around input, the only sensible approach is progressive enhancement.

Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.

The Business Case for Progressive Web Apps - Cloud Four

Jason looks at the business reasons for and against building progressive web apps. In short, there’s everything to gain and nothing to lose.

Seriously, why would you not add a Service Worker and a manifest file to your site? (assuming you’re already on HTTPS)

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

That’s how you get the holy grail of resilience and performance:

Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.

I sincerely hope other frameworks are paying attention to this layered approach.

Oh, and I also like this observation:

There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.

Progressive Web Apps Dev Summit | hiddedevries.nl

Hidde’s write-up of the Progressive Web App Dev Summit:

It was exciting to hear about the technologies, and to see that a lot of them already work on a great deal of platforms. Most of the major browser vendors expressed how much they liked the idea, so it is realistic to say support will increase in the short term. This, and the fact that all PWA techniques can be regarded as a ‘progressive enhancement’ (with some leniency as to what that term means), entails that we can build Progressive Web Apps today.

Hopefully, we will do so responsibly. Native apps really only work on their particular platforms. PWAs, in theory, can be built to work universally. For everyone with a web enabled device. This is awesome! Major browser vendors are behind the idea, and I think as developers we should be, too.

Resilience Poster Talk from Jeremy Keith by jessman5Stuff on Etsy

This beautiful poster could be the ideal decoration for your home or office.

You can download the original size (DIN A3) and print it to hang it on the walls in your office or wherever you want.

Enhancing Optimistically | Filament Group, Inc., Boston, MA

I love the thinking that Scott puts into all aspects of building on the web. Here, he outlines a really robust approach to cutting the mustard for progressive enhancement.

The web is catching up on mobile

A good impartial overview of progressive web apps, as described at the most recent Google I/O. This is very telling:

At the start I found the term a bit confusing as some PWA examples are single page applications (SPA) controlled by JavaScript. These apps are not strictly using progressive enhancement where JavaScript is added on top to enhance the experience.

The term also begs the question; what is the difference between websites and apps? It seems many of the new capabilities fit well for any dynamic website, not just apps.

Anyhow. It’s good to have an umbrella term to talk about these things.

as days pass by — Programmatic Progressiveness

Stuart’s ideas for Lighthouse sound a lot like the resilience validator tool that Scott mentioned recently.

This is our chance to help stamp out sites that don’t do things right, and help define that a progressive web app should actually be progressive.

If you have ideas on this, please file an issue.

Progressive Enhancement and Modern JavaScript ― Caolan

I think JavaScript frameworks have been blinkered to the needs of many developers (most websites are not SPAs or run by Node, nor should they be) for too long. We need to find a way to apply the lessons of modern frameworks to the rest of the web - it would be sad if everyone had to run JavaScript on their server and good-old resilient HTML was considered only as a fallback.

DRY: Do Repeat Yourself - QuirksBlog

Y’know, I think PPK might be on to something here. It’s certainly true that developers have such an eversion to solving a problem twice that some users end up paying the cost (like in the examples of progressive enhancement here).

I will be pondering upon this.

turbolinks/turbolinks: Turbolinks makes navigating your web application faster

I really, really like the approach that this JavaScript library is taking in treating Ajax as a progressive enhancement:

Turbolinks intercepts all clicks on a href links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

During rendering, Turbolinks replaces the current body element outright and merges the contents of the head element. The JavaScript window and document objects, and the HTML html element, persist from one rendering to the next.

Here’s the mustard it’s cutting:

It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.

This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.

Pakyow Web Framework

This looks like a really interesting server-side framework for Ruby developers. The documentation is nice and clear, and puts progressive enhancement at the heart of its approach.

No Really, For Everyone | Benjamin Listwon

A heartfelt call to web developers to consider the needs of the many and varied people trying to use what we build.

None of this is about Javascript. None of this is about CSS transforms or WebGL. None of this is about technology at all.

It is about making products that serve all users equally. It is about putting ourselves in others’ shoes. It is about trying to imagine the frustration and difficulty of using our products when the conditions aren’t what we’re used to. It is about being human.

Developing Dependency Awareness – Smashing Magazine

A typically superb article by Aaron. Here, he breaks down a resilient approach to building for the web by examining the multiple ways you could add a button to a page. There’s a larger lesson here too:

We don’t control where our web-based products go or how our users access them. All we can do is imagine as many less-than-perfect scenarios as possible and do our best to ensure our creations will continue to do what they’re supposed to do. One of the easiest ways to do that is to be aware of and limit our dependencies.

Building Web Apps for Everyone - O’Reilly Media

Here’s a fantastic and free little book by Adam Scott. It’s nice and short, covering progressive enhancement, universal JavaScript, accessibility, and inclusive forms.

Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.

Did I mention that it’s free?

Render 2016 - Jeremy Keith on Vimeo

Here’s another version of my talk Resilience—the same one I gave at Beyond Tellerrand—this time from the Render conference in Oxford.

Jeremy Keith on Vimeo

Here’s the video of the talk I just gave at the Beyond Tellerrand conference in Düsseldorf: Resilience.

Rebuilding the Perch UI - not your usual redesign

The Perch Control Panel is progressively enhanced. Almost all functionality of Perch is available even if you completely disable JavaScript, or if JavaScript fails to load.

An Event Apart News: The Contributions of Others: A Session with Jeremy Keith

Eric asked me some questions and I was only too happy to give some answers.

RAFP: a proposal for performance measurements through requestAnimationFrame - QuirksBlog

Here’s an interesting proposal from ppk: use requestAnimationFrame to gauge how performant a browser in behaving and then enhance accordingly.

Introduction to Ember FastBoot by Tom Dale on Vimeo

I’m so happy that Ember is moving to a server-side rendering model. Not only that, but as Tom points out here, it’s crucial that the server-side rendering is the default and the client-side functionality than becomes an enhancement.

Bruce Lawson’s personal site  : One weird trick to get online — designers hate it!

I don’t care about Opera Mini (I’m not its Product Manager). In the same way, I don’t care about walking sticks, wheelchairs, mobility scooters or guide dogs. But I care deeply about people who use enabling technologies — and Opera Mini is an enabling technology. It allows people on feature phones, low-powered smartphones, people in low-bandwidth areas, people with very small data plans, people who are roaming (you?) connect to the web.

Design is choice by Jaime Caballero

A lovely outlook on designing with progressive enhancement:

There will always be users coming from places you didn’t expect, using devices you didn’t test for.

Simon McManus - YouTube

Come for the videos of EnhanceConf. Stay for the skateboarding beagle.

An update (March 2016) on the current state & recommendations for JavaScript …

Making web apps? Care about SEO? Here’s Google’s advice:

Use feature detection & progressive enhancement techniques to make your content available to all users.

Maybe we could tone down the JavaScript / fuzzy notepad

Accept that sometimes, or for some people, your JavaScript will not work. Put some thought into what that means. Err on the side of basing your work on existing HTML mechanisms whenever you can.

If you’re going to override or reimplement something that already exists, do some research on what the existing thing does first. You cannot possibly craft a good replacement without understanding the original.

Remember that for all the power the web affords you, the control is still ultimately in end user’s hands.

Embracing simplicity by Adam Silver

The full text of Adam’s excellent talk at EnhanceConf.

EnhanceConf - Stefan Tilkov - How to embrace the browser - YouTube

The videos from EnhanceConf are started to go up already. Stefan’s talk really struck me—all the talks were great but this one had the most unexpected insight for me. It really clarifies a lot of ideas that I’ve been trying to articulate, but which Stefan crystalises by taking the long-zoom view.

The New Web Typography › Robin Rendle

A wonderfully thoughtful piece on typography, Jan Tschichold and the web. This really resonated with me:

It’s only been over the past year or so in which I’ve recognised myself as a ‘Web designer’ with a capital W, as I now believe that something happens to information and technology, and even typography itself, when people pass through these interconnected networks and interact with hypertext.

It’s for these reasons that I don’t believe in “digital design” or “designing for screens” and it’s why I’m often attracted to one particular side of this spectrum.

Robin proposes three “principles, suggestions, outlines, or rather things-that-I-ought-to-be nervous-about when setting text on the web”:

  1. We must prioritise the text over the font, or semantics over style.
  2. We ought to use and/or make tools that reveal the consequences of typographic decisions.
  3. We should acknowledge that web typography is only as strong as its weakest point.

There’s an in-depth look at applying progressive enhancement to web type, and every single link in the resources section at the end is worth investigating.

Oh, and of course it’s beautifully typeset.

Keeping a smart home guest-friendly — Sensors and sensibility

In web development, we have this concept of progressive enhancement, which means that you start by building websites with the very most basic blocks - HTML elements. Then you enhance those basic elements with CSS to make them look better, then you add JavaScript to make them whizzy - the benefit being that if the JS or the CSS fail to load, you’ve still go the basic usable blocks underneath. I’m following this same principle in the house.

Related: this great chat between Jen Simmons and Stephanie Rieger.

Progressive Enhancement Gets a Conference, From the Notebook of Aaron Gustafson

Aaron interviews Simon who’s organising the upcoming EnhanceConf which is going to be ruddy good.

Ethical Web Development

I really, really like these principles. Time to add them to the list.

The accessibility stack: making a better layer cake » Simply Accessible

A great description of a solid architectural approach to building on the web (and not just for accessibility either).

EnhanceConf line-up by Simon McManus

This is shaping up to be a great affordable one-day event in London on March 4th. The format will be similar to Responsive Day Out.

I suggest you grab a ticket.

Words of Wisdom from @adactio - Matt Radford

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.

JavaScript web apps considered valuable · molily

A response to a rant I linked to recently.

The solution for bad JavaScript web apps is not to abandon them altogether, but to make better ones.

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.

JavaScript is the best technology to build excellent interactivity in the browser. Still, the most important skill of a client-side JavaScript developer is to know when not to solve a problem with client-side JavaScript. It’s always more robust to solve a problem further down in the stack.

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.

Don’t tell me what my browser can’t do! by Christian Heilmann

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.

Yes, this is an argument for progressive enhancement. No, that does not mean you can’t use JavaScript.

You can absolutely expect JavaScript to be available on your end users computers in 2016. At the same time it is painfully naive to expect it to work under all circumstances.

Why I hate your Single Page App by Stefan Tilkov

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.

Reimagining Single-Page Applications With Progressive Enhancement – Smashing Magazine

Some really great thinking here by Heydon on how to make single page apps but using HTML for the views instead of relying on client-side JavaScript for the rendering. He explains the code he’s using, but what really matters here isn’t the specific solution; it’s the approach. Smart!

The Problem with Progressive Enhancement by Alex Lande

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.

Specifically:

  1. Performance—”Progressively enhanced behaviors like using links that point to real URLs, or server-side form submission handling, allow users to perform important actions before JavaScript loads.”
  2. Resilience—”If users can perform critical tasks when your JS breaks, it’s a minor inconvenience instead of a show stopper.”
  3. Business, Business, Business.

Photo upload and progressive enhancement for FixMyStreet / mySociety

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.

What Progressive Web Apps Mean for the Web - Telerik Developer Network

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.

Putting My Patterns through Their Paces ◆ 24 ways

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.

Progressive Enhancement—Ain’t Nobody Got Time for that | GlückPress

Two sides of a debate on progressive enhancement…

Andrey “Rarst” Savchenko wrote Progressive enhancement — JS sites that work:

If your content website breaks down from JavaScript issue — it is broken.

Joe Hoyle disagrees:

Unlike Rarst, I don’t value progressive enhancement very highly and don’t agree it’s a fundamental principle of the web that should be universally employed. Quite frankly, I don’t care about not supporting JavaScript, and neither does virtually anyone else. It’s not that it doesn’t have any value, or utility - but in a world where we don’t have unlimited resources and time, one has to prioritise what we’ll support and not support.

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.

See also: Mike Little’s thoughts on progressive enhancement and accessibility.

The web will always be a moving target : Eclectic Dreams

Caution:

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.

Reminder:

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.

Universal React ◆ 24 ways

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 user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.

YES!!!

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:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Progressive enhancement needs better advocacy • Zetafleet

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”.

Honestly, I think that plenty of developers just aren’t thinking about it—especially if they’re relying on a particular tool or framework to save them time and effort (which is not a crime). So that’s why I agree with the title of this piece: let’s talk about this more; let’s make sure developers understand what they’re doing when they make JavaScript a requirement for basic functionality.

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.

Drag and Drop File Uploading | CSS-Tricks

This is a terrific example of progressive enhancement in action: going from a simple file input to a lovely interactive drag’n’drop interface.

The code uses jQuery but it could be easily adapted to vanilla JavaScript, and anyway, it’s not so much the code that matters, it’s the approach.

Blocked! - O’Reilly Radar

Following on from that Wired article I linked to about disabling JavaScript, Simon St. Laurent brings in another factor—content blockers on iOS:

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:

Turning off web fonts, CSS, and images will frustrate designers and limit user interface possibilities, but turning off JavaScript might mean that we have to reconsider the architecture of our applications. Without JavaScript, the Web returns to its foundations of HTTP requests returning pages, with links and form submissions as the backbone of application structure.

Instant Loading Web Apps With An Application Shell Architecture | Web Updates - Google Developers

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…

Yay!

…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.

Best viewed with - Velocity Amsterdam 2015 // Speaker Deck

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?

Delivering Responsibly

The full transcript of Scott’s excellent presentation on performance and progressive enhancement.

EnhanceConf — Call For Proposals

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?

Official Google Webmaster Central Blog: Deprecating our AJAX crawling scheme

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.

Jeremy Keith - Responsive Field Day 2015 - YouTube

Here’s the 20 minute talk I gave at the inaugural Responsive Field Day in Portland.

Miranj: Collateral Damage

Websites should not come with minimum software requirements.

An Event Apart News: Enhance! by Jeremy Keith—An Event Apart video

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.

More Proof We Don’t Control Our Web Pages, From the Notebook of Aaron Gustafson

Aaron collects some recent examples that demonstrate

  1. why we should use HTTPS and
  2. why we should use progressive enhancement.

The tough truth of reality by Chris Taylor

Progressive enhancement is not about “what if users turn JavaScript off” but “what happens when the page is loaded in sub-optimal circumstances”.

A fictional conversation about progressive enhancement

So a web app is defined as a system that requires the JavaScript excesses for it to work. And the argument for the JavaScript excesses is that we need it to build web apps. That sounds a teeny bit circular to me.

Jeremy Keith – Enhance! – Beyond Tellerrand Düsseldorf 2015 on Vimeo

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.

Making Charts with CSS | CSS-Tricks

What a lovely bit of progressive enhancement—styling data tables to display as charts.

Edge Conference 2015 - 5 Progressive Enhancement - YouTube

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.

Designing with Progressive Enhancement — sixtwothree.org

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

It’s time to progress

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.

Why availability matters

A superb illustration of why playing the numbers game and dismissing even a small percentage of your potential audience could be disastrous.

It’s not 1% of people who always can’t see your site and 99% of people who always can. It’s 1% of visits. Almost all the people who don’t get your site correctly actually should have been able to. They don’t have JavaScript turned off. They’re not browsing on a WAP phone over a 2g connection from a shanty town. They’re you, in a cellar bar or a hotel room or waiting for the phone network to wake back up.

Thriving in Unpredictability - TimKadlec.com

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.

as days pass by — Availability

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.

Progressive Apps: Escaping Tabs Without Losing Our Soul – Infrequently Noted

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.

Interface Experience Maps, From the Notebook of Aaron Gustafson

This sounds like it could be a very useful tool to introduce early in projects to get a shared understanding of progressive enhancement.

Dev.Opera — Making websites that work well on Opera Mini

Using Progressive Enhancement makes your site better for all users and enables the 275 million users of Opera Mini worldwide.

How we built the new gocardless.com — GoCardless Blog

A classic example of the holy grail of web performance and robustness—start with regular HTML sent from the server, enhance once it’s in the browser …if the browser is capable of it. In this case, it’s using JavaScript (React) on both the server and the browser.

A few quick links and thoughts on big web problems – Baldur Bjarnason

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.

Making a difference with performance by Jaime Caballero

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!

The JavaScript-Dependency Backlash: Myth-Busting Progressive Enhancement

Progressive Enhancement remains the best option for solving web development issues such as wide-ranging browser support, maintenance and future-proofing your application.

The Many Faces of The Web

Instead of coming up with all these new tools and JavaScript frameworks, shouldn’t we try to emphasize the importance of learning the underlying fundamentals of the web? Teach those who are just stepping to this medium and starting their careers. By not making our stack more and more complex, but by telling about the best practices that should guide our work and the importance of basic things.

Killer page load performance – Async

This Async event at 68 Middle Street on June 11th looks like it’s going to good (and relevant to my interests).

It’s a Website | treevis

Apps:

Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.

Websites:

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.

The Web (Browser) We Forgot - Kimberly Blessing (Think Brownstone) keynote - YouTube

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.

Everyone has JavaScript, right?

And that’s why you always use progressive enhancement!

screen shot from the TV series Arrested Development, showing a character whose catchphrase began 'And that's why...'

Progressive enhancement with handlers and enhancers | hiddedevries.nl

I like this declarative approach to associating JavaScript behaviours with HTML elements.

Keeping it simple: coding a carousel by Christian Heilmann

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.

Let Links Be Links · An A List Apart Article

A superb piece by Ross Penman on the importance of being true to the spirit of the web.

Responsive News — We’ve made it.

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.

Zen and the Art of Wearable Markup

Jeffrey muses on progressive enhancement and future-friendliness.

js;dr = JavaScript required; Didn’t Read.

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.

Access Optional - TimKadlec.com

It will come as no surprise that I agree with every single word that Tim has written here.

BBC - Future Media Standards & Guidelines - Accessibility Guidelines v2.0

The minimum dependency for a web site should be an internet connection and the ability to parse HTML.

Progressive Enhancement is not about JavaScript availability. | Christian Heilmann

A great description of progressive enhancement.

Progressive enhancement in its basic form means not making assumptions

Making the case for Progressive Javascript — The Millstone — Medium

I think we can all agree that “isomorphic JavaScript” is a terrible name for a good idea. I quite like calling it “portable JavaScript”, but here’s a good case for calling it “progressive JavaScript.”

(Right up until the end when the author says “But mainly, it’s pretty safe to assume JavaScript will just work. Everywhere.” …which is precisely the kind of unfounded assumption that leads to the very problems that isomorphic/portable/progressive JavaScript can help fix.)

Better SVG Fallback and Art Direction With The <picture> Element

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).

Progressive Enhancement and Data Visualizations | CSS-Tricks

A nice little pattern for generating a swish timeline in SVG from a plain ol’ definition list in HTML.

The Practical Case for Progressive Enhancement — sixtwothree.org

You know what? Just go and read everything that Jason writes, okay?

Ruddy good stuff.

Designing Experience Layers — sixtwothree.org

The engineering benefits of building websites with a layered approach.

Why, yes, I am talking about progressive enhancement yet again! Why do you ask?

You’re Missing the Point of Server-Side Rendered JavaScript Apps : Tom Dale

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!

Experience Development pt. 2: Progressive Enhancement with Jeremy Keith on Huffduffer

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!

The Long Web by Jeremy Keith – An Event Apart Video on Vimeo

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.

Over It by Brad Frost

So keep things simple. Build to standards. Use progressive enhancement. Don’t try to send wheelbarrows full of JavaScript down the pipes unless you have to. Don’t make assumptions.

A Long Journey Reaches a Happy Conclusion: The Uncertain Web is Out In All Formats

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.