Progressive Enhancement 101: Overview and Best Practices

Progressive Enhancement 101: Overview and Best Practices

With an ever-growing variety of browsing situations and platforms that must be supported, the concept of progressive enhancement has become a hot topic of conversation. Put simply, progressive enhancement is the technique of building websites with strong foundations so that it’s accessible to the wide range of browsing situations — from mobile devices and netbooks, to desktops and screen-readers.

What Is Progressive Enhancement?

In its simplest conceptualization, progressive enhancement is the separation of HTML, CSS and JavaScript. That’s it, really. If you had to remember one thing about progressive enhancement, it should be that.

Think of these web technologies as being in layers, with HTML as the first layer, CSS being the second, and JavaScript (and other client-side technologies that deal with site interactivity, such as Flash or Java applets) as being the third.

By compartmentalizing these website components, we more easily allow our sites the ability to become enhanced depending on the web browser’s capabilities.

How would we pragmatically carry out progressive enhancement?

Benefits of Applying Progressive Enhancement Techniques

You should keep in mind that pragmatically implementing the separation of the markup, styling, and behavioral layers would give you many benefits in your site projects. These are the major reasons for embracing progressive enhancement:

Let us talk about each one a little bit more.


Accessibility of websites is one of the most important reasons for the separation of the three layers. You can be sure that all browsers and devices at least will be able to render the most important part: the content.

Think of modern browsers, ancient browsers, mobile devices, search engine crawlers and screen readers — at the very least, progressive enhancement’s emphasis on layer separation, universal design, and semantic markup allows all of them to access the content.

This implies, for example, that if there is any hidden content that is revealed by listening to a user event with JavaScript (such a mouse click on a button element), it must still be accessible somehow even when JavaScript is not available. You want that content to be accessible so that Google’s web spider can index it and blind people can read it with their screen-reading software.

Making sure all content is within reach by writing good HTML, CSS and JavaScript has tremendous and wide-ranging beneficial results.


Progressive enhancement doesn’t code for particular web browsers; it seeks to cater to all browsers as best as it can, taking advantage of a browser feature if it has them.

Smartphones and mobile devices that support media queries, CSS3 and HTML5, under progressive enhancement principles, will have an enhanced user experience because of these browser features. And with proper technique, these enhancements don’t alienate those who don’t have these browser features.


When separating a site build into different layers, developers can much better focus on their specific jobs. It is very common in larger projects that different developers have their main tasks in a different layer and/or module, e.g., one works with front-end web development, the other may focus on web design, and another deals with server-side scripting.

Layer separation also makes a website easier to maintain. If patches need to be made in the presentational layer, then you can do so without having to deal with the markup and behavioral layer.

Site Performance

Increased web page performance is a residual benefit of applying progressive enhancement principles. How does progressive enhancement help page-loading times? One could argue that putting all content, styling and scripts in a single HTML document is fastest, since it requires only one HTTP request instead of (a minimum of) three. While this is true, it only goes for the first unprimed browser cache request. Subsequent requests will greatly benefit from browser caching: externally linked CSS and JavaScript files are still available on the client’s side when they navigate to a different web page; only new content and page assets need to be downloaded and rendered. This results in fewer data going across the wire, and thus, quicker response times.

Separating the layers often results in a better perceived performance as well. When loading and executing stylesheets and scripts at the right moment in an HTML document, you can optimize rendering sequence, which in turn makes the web page feel more responsive.

For instance, the user should first see the (styled) content. Putting a script (too) early in the HTML document will block rendering of the content below it until the script is loaded. By decoupling the JavaScript layer from the CSS and HTML layer, we can more easily pick where we load our scripts; for example, we can load it after the stylesheet has been downloaded.

General Principles for Developing with Progressive Enhancement

How do we apply the concept of progressive enhancement in site builds? Let us look at the three layers to see what things we can do to promote progressive enhancement within them.


About twenty years ago, when there was a need for an internet-based document standard, HTML was invented. And even with the fast-changing nature of the web, HTML is still the fundamental content-structuring mechanism for websites.

We are now lucky enough to have reached exciting times with HTML5 (and web browsers that support it), giving us access to unprecedented semantic and interoperable markup that make our content even more machine-readable.

However, even though the language has witnessed improvements and revisions over the years, the principle purpose is still the same: We use HTML tags to structure our content and use hyperlinks to link to other (HTML) documents.

Progressive enhancement embraces this principle to the fullest — it tells you to mark up your content semantically and make sure all content is accessible through normal hyperlinks. For example, remotely loaded content (through Ajax) must still be accessible when JavaScript (and CSS) is not available on the user agent — and with the appropriate technique, this is possible (and a best practice) with just a little bit more effort.


Visual design is powerful. On the web, we have CSS, images and fonts to help enhance our message by allowing us to customize the look of our sites.

Coupled with HTML5 is CSS3 — giving designers more possibilities and freedom to express themselves stylistically in the web designs they create.

To translate our visual design to the medium of the web, we use stylesheets. Stylesheets are linked from within HTML documents, and the browser renders the rules we define in it.

The separation of websites into the three layers means that our web designs must be accessible and usable regardless of what browser the user is using. If a user is using IE6, for example, they mustn’t be barred from being able to gain access to a website’s content, even if the site enhances the user experience and visual complexity on CSS3-supporting browsers.

Progressively enhancing the styling of our sites also means that relying on CSS to render content (which is the job of the markup layer) using the content CSS property, for instance, is not a good practice unless the content is not critical to the understanding of the HTML document.


In the early days of the web, HTML documents weren’t much more dynamic than normal paper documents. In fact, the original purpose of HTML was to mark up scientific paper documents and make them interlinked for easier referencing and research.

It was about 1996 when JavaScript came into the scene. Since then, and up until more recently, scripts have usually been set up for document manipulation, form input validation and some visual effects like mouseover states on buttons and images (in the so-called DHTML period).

Although JavaScript added complexity and interactivity to the previously static HTML documents, use of JavaScript in general was superficial at best, and abusive at worst (pop-up windows, disabling user inputs such as right-clicking, and so on).

When user-centered design and "Web 2.0" reached fruition, rich internet applications entered the scene, and JavaScript, once an arguably dispensable part of a website, now functions as a critical component.

Some structure and best practices are required to develop and maintain usability and accessibility of robustly featured and highly interactive web applications and websites.

A better understanding of the prototypal nature (and object-oriented uses) of the language and the rise of numerous libraries and frameworks such as jQuery and MooTools have ultimately improved the implementation of JavaScript in standardized ways that promote (and even indirectly impose) JavaScript and progressive enhancement best practices.

To know the language (and its quirks) and to use the right tool for the job is essential to all web developers using JavaScript.

Though it is more and more difficult to create complex applications without the use of JavaScript, web accessibility practices for web applications under WAI-ARIA guidelines is a step in the right direction.

For efficient and robust web development that emphasizes on progressive enhancement, I would absolutely recommend following these guidelines:

Graceful Degradation vs. Progressive Enhancement

Graceful degradation is an older concept that’s the predecessor of progressive enhancement in web design.

Graceful degradation emphasized on fault-tolerance and was more browser-oriented rather accessibility-oriented, allowing websites to degrade when older web browsers are in use.

Progressive enhancement is different in that the philosophy is almost reverse: you enhance a website by taking advantage of features detected within the user’s browser, instead of developing for the lowest common denominator.

The philosophy of progressive enhancement, on the other hand, says that we give user agents what they are capable of handling. For example, we will let web browsers that support CSS3 (like border-radius: 4px;) apply the style rule to our web pages.

Progressive Enhancement: Issues in the Real-World

Here are a couple of important issues of progressive enhancement that you will likely run into when attempting to apply progressive enhancement principles in your site builds.

Web Apps/Rich Internet Apps Will Require Client-side Scripting

In an age where the stuff we are seeing in the browser mimics the functionality and robustness of desktop apps, the behavioral layer is a requirement that can’t be taken away if we want to allow rich and responsive experiences.

The key point to keep in mind here is that you should just be aware of the implications to user agents that don’t have JavaScript (or Flash or Java applets or whatever behavioral web technology you are developing under), so that you may respond accordingly to these less-than-optimal situations. Progressive enhancement takes advantage of features that the browser has, giving users with particular browser features an enhanced experience. In the extreme interpretation of this philosophy, browsers that aren’t capable of rendering JavaScript won’t have as rich of an experience as those that do.

37Signal’s Basecamp project management web app displays a screen-reader accessible message when JavaScript is turned off.

Progressive Enhancement Requires More Development Work

In practice, you will find yourself having to do more work when creating progressively-enhanced websites. Whether it’s learning (like what you’re doing now) or revising markup for semantics and flexibility, or coding extra CSS to take advantage of CSS3 and HTML5 on browsers that support it — progressive enhancement involves more web development time than usual.


Progressive enhancement is a powerful development philosophy for creating universally accessible sites and web apps. It does require some learning, experience and discipline, but the return of investment is high.

Additional Reading on Progressive Enhancement

Related Content

About the Author

Lars Kappert is a front-end web developer and IT specialist from the Netherlands. His development style focuses on pragmatism and creating web products for real-world scenarios. Visit his portfolio site: WebPro. Follow him on Twitter as @webprolific and connect with him on LinkedIn.

This was published on Feb 11, 2011


Vivek Parmar Feb 11 2011

great article and nicely explained.

Thank you for making these concepts and platforms much more understandable!!! Great writing…

Cogito Feb 11 2011

Nice reminder of what PE is. Thanks! :D

Isiah Feb 11 2011

Having spent the evenings of the last few months hauling my c2004 site into the ‘modern’ era, the process of achieving these best practices can be hard work for an amateur site owner. But nevertheless well worthwhile if for no other that once it’s been done future design and style upgrades (and other usability upgrades) become so much more easier to implement.

Also as Lars mentioned, stripping out old javscript rollover buttons has reduced my pages in size by around 40-60% depending on content, made them more spider-friendly, added to usability and made them faster to load.


Daniel Suarez Feb 11 2011

It is a very interested concept something we sometimes take for granted.

wordtoyourtom Feb 11 2011

What do you mean by ‘Avoid browser-specific code’ – isn’t that a part of progressive enhancement? Writing code that’s optimized for specific browsers?

(i.e. You might use -moz-box-shadow to put a shadow on a div specifically in Firefox, since it can support the box-shadow property with that vendor prefix.)

P.S. you’re good looking.

Young Feb 11 2011

I think it’s worth noting that if you don’t take the time to plan out your site structure and functionalities, progressive enhancement / graceful degradation (two sides of the same coin, really) is very difficult to achieve. Deciding on exactly how the user interface will behave will help you choose what tool (e.g. a jQuery function) is the most appropriate. Otherwise you end up tacking things on later and, though more on the backend than frontend, you risk your “modularity.”

The article was very enjoyable – it was very well constructed and to the point.

cancel bubble Feb 11 2011

What would have been really nice is a supplement to this article that actually shows a very small progressively enhanced page. I think this would help people who have never done PE as they could view it in various browsers/devices and inspect the code.

Kurt Schlatzer Feb 11 2011

“Progressive Enhancement” was coined by Steven Champeon of in a series of articles and presentations for Webmonkey and the SXSW Interactive conference between March and June 2003.

James Brocklehurst Feb 11 2011

I’ve often wondered how the the current push for HTML5 sites that rely on JavaScript to work at all in some browsers fits in with the PE approach.

Could be it gets left behind in the rush to play with the new stuff.

Interesting timing since I was having this debate/discussion with a colleague this very week. Even presenting all the benefits of Progressive Enhancement, the argument that I got back was “but JavaScript is ubiquitous, and less than 0.1% of our visitors have it disabled or are using screen readers – where’s the return on investment?”. So this is a philosophical approach – regarded as best practice, but even given the stated benefits, there’s still a cost that has to be justified.

Ben Graves Feb 11 2011

This is exactly why I’ve been trying to explain to people why it’s too early use the semantic HTML5 tags. If you can’t style them in CSS without a JavaScript hack then you’ve broken accessibility in over 50% of browsers

@wordtoyourtom: “avoiding browser-specific code” is indeed part of PE, but not directly. Things like using external scripts can be considered a “must have” when going the PE route, but it is up to the developer to correctly implement the strategy within that script (i.e. test browser features before using them).

@cancel bubble: you may have a look at my own website, which I consider a nice example of PE. I have a very minimal yet illustrative Javascript enhancement on the “experience” page: the “project” sections are visible without Javascript, but can be shown/hidden with Javascript enabled.

In general, the article was meant to be a bit more theory than practice. Examples can be found in the “additional reading” links.

Jacob Gube Feb 12 2011

@wordtoyourtom: I agree with Lars’s response. Browser-specific code like conditional comments and stylesheet hacks for IE is more like graceful degradation/fault-tolerance, rather than progressive enhancement.

Vendor prefixes are sort of gray areas, but personally, I think they’re just transitional stuff/necessary evil that will be gone once specs have been finalized. And they’re not browser-specific code in the same sense of stylesheet hacks and conditional comments. They function the same way, and there are some syntax discrepancies in some of them (like for the linear-gradient() value notation), but for the most part, their syntax and purpose is consistent. You’re not hacking padding/margin, for example, just for IE6. You’re enhancing your design for browsers with more features. A subtle, but important, difference. Browser hacks break your site for the browsers the hacks were meant for; -moz-border-radius does not.

Shruti (NENM) Feb 12 2011

Accessibility and site performance are something that users notice and the business owners understand. It has become difficult to get our clients to appreciate the work that goes behind the scenes to make sure the websites conform to these principles. I happened to point this article to one of our potential customers and they understood this well.

Thanks for a great article.

Pedja Feb 14 2011

All this is nice to talk, but when it comes to large sites that makes some real money, then PE/GE falls down. No one wants to risk and show ugly site to user, that will make user to leave site. At the end front end guy will make site to have same look and feel in every browser. This is ok for smaller sites and blogs, where front-end team is one man show. And then we have designers who sell their knowledge by showing their own site, can they risk and make site that will look different in different browser. Than they would be marked as somene who doesn’t know how to code site properly. Last one category is loudest when it comes to PE/GD site optimization. Money is only thing that will decide how to make site (revenue/cost of support), and visitors statistic will decide when to drop or add support for some browser.

PixelTunnelVision Feb 14 2011

Great article. I’d like to clarify that “in the so-called DHTML period” is kinda weird, since DHTML = Html+Css+Javascript. People don’t mind flinging around terms like ‘Ajax,’ but DHTML is suddenly antiquated? It’s still the name of the game. I know a lot of people nowadays don’t whip up DHTML solutions themselves and mostly rely on libraries and jquery function calls, but DHTML wasnt/isn’t a ‘so-called’ thing. It’s just a concept that blends those three things for the purpose of working with the browser for effects and interaction.

Jacob Gube Feb 14 2011


The term “DHTML” has fallen out of use in recent years, as DHTML scripts often tended to not work well between various web browsers. DHTML may now be referred to as unobtrusive JavaScript coding (DOM Scripting), in an effort to place an emphasis on agreed-upon best practices while allowing similar effects in an accessible, standards-compliant way.


The term “DHTML” was used as an umbrella term and a buzz word much like “Web 2.0”.

You are confusing the term with the technologies.

Tom Batey Feb 15 2011

Great article, makes for very interesting reading.

As someone who tests websites, it is good to see an approach that results in a more efficient and robust website or webapp.

Lars Kappert Feb 18 2011

@Pedja: can you then explain to me why large websites using PE (like or don’t fall down? And yes indeed, visitors stats may decide which browsers to support, but this is perfectly acceptable within the PE strategy: build from standards for modern browsers and add fallback solutions for browsers that need it. Not the other way around, that’s the whole idea and that’s what “does require some learning, experience and discipline, but the return of investment is high”, imho.

Btw, expecting any website to look and feel exactly the same in IE6 and the latest FF/SA/GC is unrealistic at least and holding us back from a better web.

D. Mulder Mar 03 2011

Leuk stuk, Lars!


D. Horne Mar 22 2011

Nice write-up. Thanks.

This comment section is closed. Please contact us if you have important new information about this post.