21 The sweet candy coating...

Slightly off topic, but…

The candy coating is applied to M&Ms; in a tumbler. The sugar is sprayed into the machine while the M&Ms; tumble around. After the sugar is added, color is added in the same way and tumbled until polished.

Oh! And thanks for the article.

posted at 02:04 am on October 9, 2008 by C Bird

22 Peanuts and Candy

Lets say: one likes candy and the peanut; but no chocolate.
I found, that most of the time it doesn’t make sense to activate JS, when there is no CSS support. But sometimes there is a need for JS even with no CSS.
The workaround usually do:
on a documentReady Event, I check, if a certain CSS Property is present. Mostly I check if the body background-image is rendered. If so, I apply all the magic done with JS. If not, I just fire-up basic JS.
Example:
BASIC JS: If you have some Ajax Content, it might be a valuable information to users with JS support and no CSS support( Top3 news for example). So all users will get served with this.
Advanced JS: All kind of thick-, fancy, and greyboxes won’t work correctly ,if there is no CSS support. So only users with CSS and JS will get served with the convenient js-Lightboxes.

O, btw. Thanks or the article.

posted at 09:00 am on October 9, 2008 by Tobias Sailer

23 A step too far

Graceful degradation focuses on building the website for the most advanced/capable browsers. Testing in browsers deemed “older� or less capable usually takes place during the last quarter of the development cycle and is often restricted to the previous release of the major browsers (IE, Mozilla, etc.). Under this paradigm, older browsers are expected to have a poor, but passable experience. Small fixes may be made to accommodate a particular browser. Because they are not the focus, little attention is paid beyond fixing the most egregious errors.

That may be the way some people viewed graceful degradation, but it is certainly not the approach that I or many other accessibility-aware developers worked.

Yes, a GD website was built for the latest popular browser(s). But sites were made to be accessible in much older and less advanced browsers than “the previous version”. I designed sites that used noscript and noframes to ensure that they worked in the most basic browsers, albeit in many cases with a much reduced user experience. It may be that people with slightly older or less capable browsers would be treated as thought they had the oldest and least capable browsers, but they would still be able to access the site.

posted at 02:39 pm on October 9, 2008 by Stephen Down

24 Don't drop support

Cameron Westland:

I agree with the points laid out in the article. But where progressive enhancement falls short is in rich internet applications. I’m personally OK with requiring a certain level of browser requirement in order to experience in a certain way. I also think fostering progressive enhancement leads to things like IE6 being around even after 10 years. I find it stifling. There comes a point where you have to just drop support for older browsers because the experience on those devices is so verbose and hurts the message you are giving.

I agree that certain application-type sites might need minimum browser requirements, but most sites can offer a non-Ajax alternative or users can manage without certain features. People with older browsers know (mostly) that they can’t get the all-singing all-dancing stuff, but they still want/need to be able to access the content and basic functionality.

What has led to IE6 being around after 7 years (it was launched in 2001) is a well-known phenomenon, which is that as a particular technology becomes more widespread and pervasive, an ever smaller proportion of people keep their technology up-to-date. Opera and Firefox have got around this by prompting users to update every time a newer version is released, but IE hasn’t had that yet, so people who just want to browse that there ol’ internet use what came with their computer and that’s the end of that.

What progressive enhancement has done is to allow developers to build standards-compliant high-functioning websites that don’t alienate people with IE6. The alternative is that we would be stuck with sites designed for IE6 forever, and I don’t think that’s a better alternative!

Progressive enhancement isn’t just about catering for IE6. It also means catering for people using new technologies like mobile phones, and it is helpful for people using assistive technologies. You can’t blame good accessibility practice for the persistence of IE6!

posted at 03:06 pm on October 9, 2008 by Stephen Down

25 PE vs. GD and so on

Those pointing out that graceful degradation doesn’t differ from progressive enhancement are on the right track, as far as definitions are concerned; the problem was that for a long time in the mid-nineties and beyond, the trend in practice was towards simply winking at GD and building sites for cutting edge browsers that were then tweaked so they weren’t simply awful in older browsers. This is partly due to the fact that the technology support simply wasn’t there back then to allow for true separation of content and presentation; the primary point behind PE as a term was to give people a method to approach how sites could be built so they were usable and functional across a wide variety of browsers, and to show that it was even possible. Dave Shea’s CSS Zen Garden was just one of the first examples of the basic idea, but many people just saw it as an isolated experiment, rather than as a demonstration of the way things ought to be done in the future.

I coined the term as a replacement for the more unwieldy phrase “separation of content, presentation, and behavior for the sake of accessibility” and to give designers a method they could expand upon, using the ideas of content-driven design, minimal, semantic markup, CSS-driven presentation, and what has come to be called unobtrusive JavaScript. I’m happy to see that it has taken off as I’d intended, and I’m grateful to Aaron and ALA for helping to spread the ideas even further.

The point about “Web 2.0” sites and others with highly functional, interaction oriented interfaces being harder to do with PE methods is a valid one; I don’t think it’s impossible, but rather that it’s kind of an obvious point – if your app absolutely relies on scripted behavior, then it clearly won’t work at all in a browser that doesn’t support scripting. But I also believe that the vast majority of sites and pages are about delivering content, rather than interface, at least for the time being. And for those, PE represents a way to build those pages and sites in the most accessible way possible. And it makes for more easily maintained sites, due to the manner in which the underlying markup isn’t cluttered with presentational crud.

The fact that Yahoo, AOL, and others have embraced PE as the foundation of their design strategies is telling, and gratifying. In a way, PE was, for me, a way to get back to my roots in SGML, where we simply didn’t have presentational markup and where scripting and/or interaction was built into the applications, rather than into the underlying document source; many of us abandoned the sensible approach simply in order to keep up with the flood of new Netscape betas back in 1995, and when CSS was finally mature enough to use, it seemed important to return to those older lessons and apply them to the present day.

posted at 10:27 pm on October 9, 2008 by Steven Champeon

26 I disagree

The author seems to me to be saying, in effect, this is what ‘graceful degradation’ should have been, and then giving it the a name, never mind the fact that GD is in many places what it should have been.

What happens now when the new ‘progressive enhancement’ is done badly in a few places and the ideal is not universally realised? Do we need to come up with a new name – this is what ‘progressive enhancement’ should have been?

That said, and regardless of what we call it, the author does well to draw our attention once more to this way of developing web sites.

posted at 12:47 pm on October 12, 2008 by Ian Goldby

27 Cool Candy

I loved the candy coat example! Couldnt have been more illustrative that that.

posted at 01:09 pm on October 15, 2008 by Maneet Puri

28 I agree

the concept of “Web 2.0” began with a conference brainstorming session between O’Reilly and MediaLive International. Dale Dougherty, web pioneer and O’Reilly VP, noted that far from having “crashed”, the web was more important than ever, with exciting new applications and sites popping up with surprising regularity. What’s more, the companies that had survived the collapse seemed to have some things in common. Could it be that the dot-com collapse marked some kind of turning point for the web, such that a call to action such as “Web 2.0” might make sense? We agreed that it did, and so the Web 2.0 Conference was born. www.dreamconsultancy.com.au

posted at 04:53 am on October 16, 2008 by piyush kotadiya

29 Common sense?

Great article as always! But isn’t this just common sense?

posted at 12:52 pm on October 17, 2008 by Jonny Haynes

30 Got Candy?

I want M&Ms;!

posted at 01:13 pm on October 17, 2008 by Martin Smales

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)