Progressive Enhancement / Graceful degradation: when to use them, and practical examples

I remember Chris Pruett at Google I / O speaking about the development of real-time games on Android.
The rendundant idea of that keynote was: “prefer the flexibility over performance as long as this does not affect the user experience”.
When developing html and css this idea often echoes in my mind. If I could freely use CSS3 I would get more flexibility, more speed in loading and would improve the overall user experience.
Unfortunately, then a worm creeps in to my mind that impairs my idea of flexibility: crossbrowser support (especially support for older browsers).
Fortunately, two techniques run to our aid: Graceful degradation and Progressive enhancement: their purpose is similar, the result should be identical, what is fundamentally changing the “modus operandi” (The way it’s done).
The aim is to make the contents of the project accessible to the widest possible audience, affecting as little as possible the overall browsing experience by using two different approaches.
Graceful degradation (graceful degradation) is the technique which tries to make maximum use of the specifications of modern browsers, in fact it uses HTML5 and CSS3 specifications that could make life easier, then it creates a callback for the most “ancestral” browsers.
But the technique I prefer, because it gave me less problems is the so called progressive enhancement tecnique. The result is the same but uses a reverse procedure. We start developing for “medieval” browsers and then “enhance” the project to get the benefits in terms of flexibility, speed and ux for modern browsers.
Both techniques involve the fact that in these two categories of browsers (old and modern) your site is displayed in a different way, so it is understandable that these techniques are not usable in all circumstances.
Recently we have developed the site of a dear friend, who owns a big print center, so I wanted to use the Progressive enhancement on the quote form of the site because I believe that this project was the perfect candidate.
Choose the “perfect candidate” was quite simple. Mainly depends on two factors: the type of customer and type of audience.
In this case I was on the safe side since they use Mac and then browsers in the group of “modern browsers (Safari, Firefox, Chrome). Even the audience is ideal: a site of a print center is mainly used by advertising agencies and designers: they usually have a knowledge of computers and use a modern browser or a fairly up to date one.
But back to our flexibility talk. In the form designed by Cristina , the fields had to be coded in a specific style: The problem was that they had different sizes and types. From drop-down menus (select) to animated textareas through different measures of simple fields (text input).

If I use backgrounds to simulate the original layout, I would use different images to simulate the different sizes or a very complex markup, with “pieces” of the fields.
I could use with CSS3 rounded corners, gradients, shadows and not having any problems.


Having a double edge I need additional markup, not just the input element. The basic html code is simple:

<div class=”inputcontainer”>
<input type=”text” name=”azienda”/>

Probably this markup would be enough even to use a solution based on a background images, but through CSS3, keeping everything “parametric”, I can change an item’s properties (eg color, size) without opening an image editor. As I said before: flexibility.


The next step is to get a decent rendering in the worst browser … Lynx! Just a joke, IE6 (Internet Explorer 6)!

This is the final adjustment of the outer div:
width: 150px;
background: #ededed;
background: -webkit-gradient(linear,
left bottom, left top, from(rgb(235,235,235)), color-stop(0.6, rgb(240,240,240)), to(rgb(250, 250, 250)));
background: -moz-linear-gradient(
center bottom, rgb(235,235,235) 0%, rgb(240,240,240) 60%, rgb(250, 250, 250) 100%);
zoom : 1;
filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr=’#f7f7f7′, endColorstr=’#f2f2f2′);
padding: 2px;
font-size: 12px;
float: left;
margin-right: 10px;
-webkit-border-radius : 5px;
-moz-border-radius : 5px;

The parts that interest us are:
background: #ededed; the fallback background, just in case the rules were not supported

zoom : 1;
filter: progid:DXImageTransform.Microsoft.gradient(GradientType=0,startColorstr=’#f7f7f7′, endColorstr=’#f2f2f2′);
With these two properties we make sure that in IE6 / 7 it has a nice gradient.

More internally here is the rule for the .inputcontainer div’s son:
.inputcontainer div{
border: 1px solid #fff;
height: 22px;
-webkit-border-radius : 5px;
-moz-border-radius : 5px;
-webkit-box-shadow : 0px 1px 1px #ddd inset,
0px 1px 1px #ccc;
-moz-box-shadow : 0px 1px 1px #ddd inset,
0px 1px 1px #ccc;
All of the properties over the first 2 will be ignored by Internet Explorer (all have the browser vendor prefix).

And this, finally, the rule for the input:
.inputcontainer input{
font-size: 12px;
color: rgb(80, 80, 80);
z-index: 80;
background: transparent;
width: 115px;
margin-left: 4px;
height: 22px;
_height : 18px
Note the transparent background and the property with the underscore (_height) to correct only the rendering of Internet Explorer 6.

At the end of this first phase this is how the input looks in Internet Explorer 6:

Pretty decent in my opinion.
From here on begins the phase of enhancement: I have already pasted the key properties including the rules for modern browsers:

background: -webkit-gradient(linear,
left bottom, left top, from(rgb(235,235,235)), color-stop(0.6, rgb(240,240,240)), to(rgb(250, 250, 250)));
background: -moz-linear-gradient(
center bottom, rgb(235,235,235) 0%, rgb(240,240,240) 60%, rgb(250, 250, 250) 100%);

For the gradients of the div .inputcontainer, unfortunately, the rule must be redefined for both Firefox and webkit browser (Safari, Chrome, etc).

-webkit-border-radius : 5px;
-moz-border-radius : 5px;

The one above is for rounded edges.

-webkit-box-shadow : 0px 1px 1px #ddd inset,
0px 1px 1px #ccc;
-moz-box-shadow : 0px 1px 1px #ddd inset,
0px 1px 1px #ccc;
Here I want to focus a bit ‘more. This is the rule that made the text field incredibly similar to the one on the design. This rule defines the shadows for the Mozilla browser and for webkit.
I break below the value of the property:
0px = shadow moving from the left, may have a negative value (and moves to the left)
1px = shift from top, this one may have a negative value
1px = this value indicates how the shadow will “expand” and gently fading to the background color
#ddd = this is the shadow color (that’s the short version of the color, is in fact is #dddddd)
inset = this indicates that the shadow must be “inset”

But this is the most interesting part: another shadow value separated by commas. Yes, in practice, multiple shadows can be defined for each element in css3!

And so here’s the final input fields rendered by a browser webkit:

Almost identical isn’t it?

The complete form can be found on the website of Printing Quote Form – Printing Geny Syracuse

Starting from this basis the customization for different types of input fields was minimal. Each new size, new features (such as a minilabel on some inputs) or drop-down menu buttons work without any hacks in all browsers, only with a slightly different appearance.
The audience then has allowed me to focus a lot on the version for modern browsers and will be something that you should be very careful when you choose to use one of these techniques. After all, Internet Explorer still has a too large slice of the market, but knowing that on Vista and Seven (Windows 7) Many users will soon update their browsers to Internet Explorer 9 which supports a large part of the CSS3 specification, you can easily develop with an eye toward the future.


  • zak
    | 12.10.10 - h 14.58

    Bel post ed ottimo risultato. Unica nota dolente è che il css non è valido.

    • |12.10.10 - h 15.11

      Hai ragione Zak, il css non è valido purtroppo.
      Si potrebbe fare un 2° foglio di stile chiamato enhancement.css con le regole css3.
      Io al giorno d’oggi preferisco concentrarmi su un html valido per motivi di accessibilità e compatibilità, mentre tralascio spesso la validazione del css concentrandomi più sulla compatibilità cross browser (anche per accessibilità) che sulla validazione vera e propria. (quante volte ho scritto validazione?)

  • Joe
    | 14.10.10 - h 10.33

    good points and the details are more precise than somewhere else, thanks.

    - Joe

Lascia un commento

  • Wordpress
  • Ford Focus
  • Monitor Samsung
;-) Thanks for visiting