Progressive Enhancement without rainbows & unicorns
--
Let’s quickly break down PE, GD & RE so we’re all on the same page.
Graceful Degradation & Progressive Enhancement “theoretically” aim for the same results except with PE you develop from legacy to more capable browsers and with GD you develop from more capable browsers to legacy. The main difference is where the priority resides.
With Regressive Enhancement you regress from more capable to legacy browsers and provide mostly equivalent functionality throughout. (i.e., jQuery library)
All three methodologies aim to make websites/ apps more accessible & available. If you’re expecting more, I guess you've just learnt something new.
This article is not advice for progressive enhancement techniques. The aim is to point out wrong usage of what it is, what it is not and the bigger picture of the web eco-system.
Likely, you are already “doing” progressive enhancement
Sounds familiar?.. You decide to (let’s say) support IE8 as the lowest denominator and as a baseline for development, then provide better or more features for “more capable” browsers. If so YOU ARE DOING PROGRESSIVE ENHANCEMENT. It doesn't imply that you don’t touch CSS3 till the last minute, it means the priority starts from a legacy baseline. WordPress is an example of progressive enhancement as an underlying principle, not just the default themes but the entire application.
Incorrect definitions
Lets look at some (mostly) exaggerated definitions of progressive enhancement from a quick Google search, this should be fun: (Bold is good, italic is WTF)
- Progressive enhancement is a strategy for web design that emphasizes accessibility, semantic HTML markup, and external stylesheet and scripting technologies.
- Progressive Enhancement is a powerful methodology that allows Web developers to concentrate on building the best possible websites while balancing the issues inherent in those websites being accessed by multiple unknown user-agents.
- Progressive enhancement is a layered approach for building websites using HTML for content, CSS for presentation, and JavaScript for interactivity. If for some reason JavaScript breaks, the site should still work and look good. If the CSS doesn't load correctly, the HTML content should still be there with meaningful hyperlinks. And even if the HTML is malformed, browsers are smart enough to continue rendering what they can.
- It enables users who disable JS to access your site.
- Progressive enhancement is the idea of designing from a most common denominator — what most users can see — and building out. It’s also the fast track to mobile-first design.
So lets put this into perspective before heads explode. The terminology progressive enhancement didn't originate within the field of web development. Progressive enhancement is used in laboratory testing, medical treatments and legislation which are just to name a few. The most important aspect is that the concept is synonymous among different fields. It’s not possible to redefine these two very specific words into a framework of rules.
Within web design, in 2003 Steve Champeon coined the term progressive enhancement as a design strategy for HTML & CSS. ( notice that there is no mention of JavaScript)
Back to the list, the first definition in the list is actually quoted from the original, but the technologies should be ambiguous since we must consider XML, SVG, Flash, Silverlight, Java applets, PDF, printing, etc. And also because of unforeseeable future technologies. It may also regrd server & protocol technologies. (PE must remain ambiguous to technologies, e.g., more sites may print in 3d from WebGL, surely that could be considered as an enhancement layer)
That last definition on the list above was by Zurb. Although, it’s not entirely what PE is, Zurb considers the common person and builds back & forth from there (if I understand right), which makes a lot of sense.
Progressive enhancement is a terminal methodology (i.e., weight loss). It is not a framework, there is no wrong way to do it as long as you’re enhancing whilst progressing from an old to new/ less capable to capable baseline and resulting in improved accessibility.
Progressive enhancement is not about maintenance, that amount of ubiquity is too much since maintenance is pretty much progressive. And it’s definitely not about disabled JS support or failure which leads me to the below…
FAILURE SUPPORT IS NOT PROGRESSIVE ENHANCEMENT
By no definition can failure support be progressive enhancement unless you give people a crappy version of something, and when that fails they get a better version.
You have a power cut, your backup power generator kicks in automatically, notice the lights are slightly pulsating because your backup power can not provide the clean sine wave as expected from your domestic supply. You expect it to be crappy & temporary. That is an example of failure support via graceful degradation. (slightly different to graceful degradations as a development process)
So you have an HTML link button, when clicked it does a little dance (via JS), makes a sound (via JS) then after opens a new window with the desired link (via a JS callback). Let’s say the JavaScript fails to load for some reason, (server issue/ connection issue/ bug) you click on the link and target _blank still allows access to the new window but without the dance & audio, that is failure support via graceful degradation. Not progressive enhancement.
The confusion
Many people are trying to tie other good ideas (& bad ideas) into progressive enhancement so they can sell it as a single packaged solution for all your development needs.
But when you build a website/ web-application you are never doing one thing, you have an underlying methodology (PE, GD and in some cases RE), and on top you use various libraries (usually RE) as abstraction methodologies, maybe with failure support (99.99% of the time GD), and maybe other forms of PD & GD. What am I getting at?
It’s not one big thing
People want one solution, but there will never be one right way to build websites. The answer to every project will always be “It depends”.
But with all that said…
The problems with progressive enhancement:
- Progressive enhancement is a solution for accessibility, but also an anti-pattern for the evolution of web development & the web’s eco-system. Because the priority resides at the lower end of the scale, it encourages a slow logarithmic progression of consistent feature support for recommended & desperately needed standards. (In other words, they know you will clean up the mess because your emphasis is mostly on supporting what is fully compatible and outdated)
- It also implies that the lowest end of support is so important that the common or modern end should compensate in priority to make a service more accessible (this can be good but can also be bad, it really depends). PE is nothing new, it is how most developers have been developing for a decade.
- Progressive enhancement is hard-wired into the culture of regressive enhanced plugins (making things work similarly on less capable browsers/ devices). Currently web browser feature support is erratic, you can’t always say “Well I’ll just leave this out” something may work in IE9, but not in Safari 5, but it’s useless if you don’t include it in Chrome because that also enables some other really cool feature usage, but that’s also glitchy in Firefox. So with those kinds of headaches you’re likely to end up layering regressive enhancements on top of PE because of time, money and sanity. With GD it is vastly easier to separate (modern browsers) and (legacy browsers) into two separate states, simply because the web is mostly backwards compatible you can for instance group Safari 5< & IE8< under the same level of suppot or maybe IE9< & Opera 12.1<. We rarely do this because we are mis-educated on what GD is and what it can be. And it appears expensive at a glance.
- If more websites emphasised priority at the forefront (whilst being accessible) it would discourage the need for too many unnecessary dependencies on regressive enhancements.
- Because PE indirectly promotes the use of RE, it makes legacy browsers perform slower than expected in the real world. Many modern libs trying to make old browsers act look and feel like new ones. But there’s a huge side effect, you’re still standing in a black box. Selenium & PhantomJS are not running in environments similar to the common legacy user. Get a Pentium 3 with windows XP, throw in some IE spyware, open up 5 social network tabs & MS Office and that my friend is closer to the common legacy user environment. Maybe it’s not the developer’s responsibility to care, and it’s not directly PE’s fault but the side effect of mass PE development is regressive enhancement. (One thing we usually forget is that many of these old PCs have high latency reads/ writes for tiny chunks, but total slowdowns for large heaps)
The “main” problems with GD
It’s harder to diagnose realistic issues with graceful degradation as it’s not often in use or promoted but of course there’s bound to be several like any paradigm. The main issues at the moment is that there are not enough people who understand what it is, and there are barely any libraries or tools that revolve around GD development. Effective GD will depend on GD specific workflows.
What should I use?
Whatever makes sense to the target audience in accordance to the progressing browser landscape. Using either GD, PE or RE shouldn't result in less or more accessibility. Using RE as an underlying principle is overkill & rarely done. Technologies are changing at an exponential rate, the majority of browsers in the near future will auto-update this is almost a guarantee with the rise of evergreen browsers, it would be naive to only consider progressive enhancement.
Graceful degradation is suited better for forward compatible experiences, the increasing speed of changing technologies and could also be more cost effective when considering upgrades & adding new features which is imperative. One thing to remember is that there is no loss of accessibility with either 3 methodologies.
The obvious twist
If a web developer is unaware of terms like “progressive enhancement”, “graceful degradation” and “regressive enhancement”, that developer would still be doing more or less one or the other. This article maybe overkill, but is it logical for us to redefine “self-defining” terms that have been used similarly for decades, if not centuries in other industries?
Define Graceful Degradation & Progressive Enhancement
Progressive Enhancement & the Future of Web Design
