In Progressive Enhancement (PE), the strategy is deliberately reversed: a basic markup document is created, geared towards the lowest common denominator of browser software functionality, and then the designer adds in functionality or enhancements to the presentation and behavior of the page, using modern technologies such as Cascading Style Sheets or JavaScript (or other advanced technologies, such as Flash or Java applets or SVG, etc.)

One of the biggest influences on my history as an HTML Geek had to be David Siegel’s Creating Killer Websites book. If Siegel beat two ideas into my ideas they had to be that images need to be optimized within an inch of their life and that websites should look and act the same regardless of what browser a user employs.

Published in late 1997, the landscape of the web has changed considerably since those nascent days of web design. Careful use of Photoshop definitely helps in the fight against bloated images along with the increasing acceptance of Portable Network Graphics (PNG) as a web standard. As long as smart decisions are made about what files get saved in which format, we should be looking good.

Yet, there fight for browser compatibility still remains one of the biggest hurdles in a web developers life. “Yes, but does it work in IE?” has become the impetus for many a late night of stylesheet and/or javascript tweaking. The question that might need to be asked sooner rather than later is, “Does this need to work the same in IE?” Or, conversely, “Does this need to work in Chrome?” While websites should still be a relatively similar experience from one browser/platform to another, are we cheating ourselves and our users by omitting a bell or whistle simply because it can’t be “heard” in another person’s experience?

That is to say, does the web experience have to be identical for everyone or are there arrows in our quiver of “web tricks” that we can let fly for those who happen to browse one way or another?

Take, for example, the use of CSS3 selectors. While these aren’t universally
accepted across the board yet, does that mean that they shouldn’t be utilized
at all until that Magical Day of Acceptance occurs? Or, is it our duty to push
the limits of our coding to include the right items in the right place? There’s
a fine line that needs to be walked there. The rule of thumb is that these progressive
enhancements shouldn’t adversely affect user experience and they should
degrade gracefully for users in older/non-compliant browsers.

sIFR is a
perfect example of a progressive enhancement. Users who have Javascript enabled
and the proper Flash plugin are privy to beautifully rendered bits of text that
are otherwise “plain Jane” to users. This doesn’t adversely effect the user
experience, merely enhancing it. For a more “behind the scenes” example, look
at some of the CSS 3 selectors. Imagine a page in which a checkbox gets a
green border when it’s checked/selected. If this happens to occur on Firefox
but not IE, is that a deal breaker? If it only happens on Opera and is seen as
a “nice to have,” should that require hours of extra coding? IMHO, no. If it
happens with a simple line of code (input:checked
{ border:1px solid #090; }) then so be it.

That isn’t to say that users should be disenfranchised. To
misappropriate/paraphrase Animal Farm, all user experiences should be
equal, but some should be more equal than others. When given the option to
enhance a site for users, do so as long as it doesn’t detract from the
experience as others. This is especially true in terms of enhancements which
may not be prima facie, such as those that will improve the experience for
differently-abled users.

Just remember to keep taking those “baby steps” forward and know that
someday browsers will catch up to where you were six months ago.

Mike White