Discuss: Test-Driven Progressive Enhancement

by Scott Jehl

1 Sniffing For Capabilities - Makes Sense

I had looked at this technique upon reading about it on javascript guru John Ressig’s blog.
An interesting and potentially very useful approach to browser sniffing.
If you have to accomodate a wide variety of user-agents old and new, check it out.
Thought-provoking at the very least.

posted at 04:52 pm on September 23, 2008 by Richard Fink

2 Untitled

This is a very informative and a nice idea for sites that use a lot of JavaScript. I think the testing code would be overkill for smaller sites that aren’t using a great deal of JavaScript. Definitely something I’ll be looking into more though, and I’m a big fan of the progressive enhancements.

posted at 05:19 pm on September 23, 2008 by Kendall Conrad

3 Brilliant (but what about JS disabled user agents?

Clearly using Javascript to test the browsers capability is clever and useful but what about users who do not have JS enabled? They end up seeing the basic version even though their browser may cope with the boxmodel or any other CSS perfectly well.

posted at 06:56 pm on September 23, 2008 by M Bruce

4 JS-Disabled - Good Question

@M Bruce: Good question and thanks for commenting. It’s true that enhancements that make use of the test script will not reach JS-disabled users, regardless of how advanced their browser may be. Assuming your site or application is functional in its “basic” mode, you might decide that this is acceptable, but keep in mind that it’s up to you to decide where the experience divisions are made and how extreme they may be. For example, your “basic” version might look quite similar to your enhanced version, aside from some more complicated enhancements that would require a blend of proper CSS and JS support (such as our sliders in demo 3).
This technique provides a framework for making experience divisions in a clean and separated manner, but how and where you make them is entirely up to your discretion.

posted at 07:29 pm on September 23, 2008 by Scott Jehl

5 FANTASTICAL

This is great. I’ve always coded with standards and degraded properly, but since recently getting a Sidekick and browsing the web more often while I’m out, graceful degradation has a renewed importance to me. It sucks when I want to look up some basic information that happens to contained in Flash.

But related to this article, it definitely sucks when I load a page that renders rather perfectly, but the status bar tells me that its forever loading a script, and eventually I’m prompted that the script should die.

It’d be useful to make Javascript checks for functions and such before trying to throw them around.

posted at 09:19 pm on September 23, 2008 by Sean McArthur

6 Use JS for bad. Then fix the bad

If you use JS to hide something that you would want to show to a client without JS, then you don’t ever run into the issue of it being inaccessible, and at the same time, you don’t have to worry about testing for effects. (ie, you have a cool animation on hover – well, put CSS :hover on like the animation doesn’t exist, and then use JS to override the whole operation.)

posted at 11:27 pm on September 23, 2008 by Michael Angeletti

7 "Support" is a fickle beast.

The testUserDevice.js code has the following test for getElementById support:

getById: function(){ return document.getElementById ? true : false; }

Note that in IE Mobile 5, this will throw a JavaScript exception, because IE Mobile 5 doesn’t support this type of object checking. One example, but testing solely on object support forces you to make a lot of assumptions about the user agent which might not be true.

Another example: Google Chrome, like all WebKit browsers supports border-raduis, but you wouldn’t want to use it .

I think Yahoo’s Graded Browser Support is a far better idea. It’s just not efficient to do this kind of testing, as your results will still be sub-par.

posted at 09:34 pm on September 24, 2008 by Ryan Cannon

8 A good progressive enhancement "booster". Ignoring

Lately, I’ve been making extensive use of psuedo classes like :hover and :focus knowing very well that they won’t be supported in all browsers.

The thing is, knowing that I’m going to do this influences my design, so I make sure that design is clear enough where these sort of CSS filigree don’t break the user experience in the slightest.

My €.02 also thinks that sniffing for a mobile device on the server side can provide a richer experience with less effort. Mbta.com spits out a rich site when viewed on the desktop, but simple text when viewed on a mobile device. Then they’re only upkeeping a few extra templates specifically designed for mobile, whereas this solution involves juggling javascript, stylesheets, etc.

posted at 12:06 am on September 25, 2008 by Eric Fields

9 Sniff, sniff..

Something about sniffing for device capabilities seems so ancient from a design standpoint.
We used to do this for browsers and deemed it as irrelevant and futile.
Why would we do this for devices when we have alternatives via good, standards based code and CSS media styles?

Sounds like another solution to a design problem that really doesn’t need to be “fixed”.

posted at 01:05 am on September 25, 2008 by Steve Buell