<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
    xmlns:admin="http://webns.net/mvcb/"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:content="http://purl.org/rss/1.0/modules/content/">

    <channel>

    <title>A List Apart: Comments on: Understanding Progressive Enhancement</title>
    <link>{url_title_path=articles/}</link>
    <description></description>
    <dc:language>en</dc:language>
    <dc:rights>Copyright 2010</dc:rights>
    <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    <admin:generatorAgent rdf:resource="http://expressionengine.com/" />




    <item>
      <title>Posted by: Robert Grant</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#1</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#1</guid>         
	  
      <description><![CDATA[...although graceful degradation is a goal; progressive enhancement is a method. You can achieve the former through bad means, or through good means. PE is an example of the latter.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Brandon Cox</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#2</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#2</guid>         
	  
      <description><![CDATA[It's often difficult to keep it all in mind as you're designing. Thanks for remind us to slow it down enough to contemplate every layer of every project.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Peter Bex</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#3</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#3</guid>         
	  
      <description><![CDATA[Thank you for the well-written article! I've never seen an explanation of such a subtle difference that was as gentle and clear as this.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Cameron Westland</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#4</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#4</guid>         
	  
      <description><![CDATA[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.

Of course this doesn't apply to blogs or simple content websites.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Nathan Walton</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#5</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#5</guid>         
	  
      <description><![CDATA[Love the article. It seems to me that one of the quickest ways to get into this mindset is simply to start browser testing a little earlier. If I'm looking at my site in straight XHTML first, it tells me a lot about how well my content is structured. If I try to come up with workable CSS solutions for my navigation (for instance), and test at that level before I even think about javascript, I ensure that I've given each level of enhancement its proper attention.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Bree Radloff</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#6</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#6</guid>         
	  
      <description><![CDATA[The info-graphic assumes that anyone actually eats M&M's for the peanut. ]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: jess heitland</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#7</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#7</guid>         
	  
      <description><![CDATA[Perhaps this comes in the next installment... But, can anyone point to some current examples of a "progressively enhanced" website?

]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Ian Beck</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#8</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#8</guid>         
	  
      <description><![CDATA[Similar to Jess Heitland, I thought the article was significantly lacking in the concrete definition and real-world examples departments.  I ended up writing a short article to hopefully complement it (particularly for people who weren't previously familiar with the idea of progressive enhancement), but I'd also love to see example websites that uses progressive enhancement.  My own examples are still incomplete or under NDA.

http://beckism.com/2008/10/progressive_enhancement/
]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Aaron Burrows</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#9</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#9</guid>         
	  
      <description><![CDATA[http://www.panic.com/coda/ - A great example of progressive enhancement.

View and navigate the site, then disable javascript. It's all still there, presented beautifully, but without some of the "experience".

Then disable CSS. The content is all there, with a clear structure, and everything is readable, usable, and informative.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: jess heitland</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/#10</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#10</guid>         
	  
      <description><![CDATA[I guess I always considered that behavior graceful degradation.

RE: Coda site...

When Java and CSS Styles are disabled the arrows for navigating the carousel (am I being 'nitpicky?') are still visible and hyperlinked. Under Progressive Enhancement, shouldn't those elements be presented in a different manner? They are useless to anyone/device lacking Java/CSS Styles.

Would PE possibly be more about the site reacting to the device? (e.g.: no java = display version A. jave enabled = display version B. no java/mobile device = display version C.)

Thanks all, just trying to understand.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Aaron Burrows</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#11</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#11</guid>         
	  
      <description><![CDATA[No, I don't think you're being nitpicky. I noticed too that the arrow links aren't unobtrusive ([removed]ScrollArrow should and could easily be made into standard links, just like the tabs at the top.)

Maybe someone else will have a better example. But I think the Coda site is pretty good, and is mostly using progressive enhancement. :-)]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Sander Aarts</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#12</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#12</guid>         
	  
      <description><![CDATA[Clients, designers, employers, project managers, etc. (I'd say anyone except for front-end developers and accessibility experts) always seem to have the opinion that the fully pimped version of the website is its only real incarnation.

Therefore I agree with "Robert Grant":http://www.alistapart.com/comments/understandingprogressiveenhancement?page=1#1 that Graceful Degradation is a goal and Progressive Enhancement is a method to achieve that goal. And for now it's probably the best method there is.

The difference between GD and PE is one of concept more than of working practise in my mind.
]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: David Penny</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#13</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#13</guid>         
	  
      <description><![CDATA[Thanks for the article. And I think the M&M analogy is great.

My eyes were opened to progressive enhancement by Jeremy Keith's Dom Scripting book and I've tried to apply the principle whenever possible since. As he says in the book, "web pages that are progressively enhanced will almost certainly degrade gracefully". 

By the way, is there any point worrying about behaviour without style scenarios (peanut and candy-coating)? 

]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: David Penny</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#14</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#14</guid>         
	  
      <description><![CDATA[Yahoo! is mentioned as an example in the article. ]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Ralph Mason</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#15</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#15</guid>         
	  
      <description><![CDATA[Thanks for this simple, straightforward article. If this approach to design catches on widely (as many other ALA concepts have) the web will surely become a better experience for all. 

The key is the statement "Content is the reason we create websites to begin with". All the fancy tricks of CSS and JavaScript etc. (wonderful as they are) distract from this fundamental point.

Even though we have fancy cars today, the roads still accommodate horse-and-cart. Every discipline has its foundation, and ours is "rich, semantic (X)HTML".

Looking forward to the following installments...]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Hans Kuiters</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#16</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#16</guid>         
	  
      <description><![CDATA[I agree with the article. It's what I believe in and tell my manager so often. But in our company, clients first want to see a great layout, and much, much later they come up with the content.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Basil Mohammad</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#17</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#17</guid>         
	  
      <description><![CDATA[I am a web designer/UI Developer. The article is a great one indeed, so thank you very much.
However I might have some comments on the whole subject.
I have been working on PE for the last 3 years without really knowing it. And itâ€™s really great!
Only last month I started studying this cross browser compatibility.  I realized that often the need for 3 or 4 style sheets is not necessary at all (itâ€™s in fact a hug NONO because of the increase of requests to the server).I found that If your work is correct and according to the W3 standards then you hardly will have any problem with the CSS, Especially if you use a tables layout (which is the hardest thing to be compatible in 4-5 big name browsers). 
I know the emphasis in PE is on the content. But often when doing web applications and systems such as intranet HR systems, the focus is set on the behavior of the user and the user experience. In this case GD is better in my opinion. There is no way that you can actually give the same user experience to all the browsers that the client might have, without having to lower the user experience.
I believe that there 2 ways to developing systems in web. First you need to lose a lot of the great experience of the user and use the PE method afterward. Or simply apply the GD and I prefer the second.
I think it is now obvious that I donâ€™t agree that PE is a method and GD is a goal. But rather 2 ways of developing depending on the environment which the application of the website will be in.
One last thing, I am currently working on a new project in am supposed to create a full User Experience bearing in mind the need for limitations of browsers in relation to JS.
I know I have made this comments long but I hope I made some sort of use to you all. And hope to get some feedback and some help and hints regarding the previous paragraph.
Iâ€™ll be waiting eagerly for the second and third part of this document.

]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Divya Manian</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#18</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#18</guid>         
	  
      <description><![CDATA[Graceful Degradation is a goal and progressive enhancement the tool to build it from ground up. Is that what this article is trying to convey? ]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Scott Olson</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P10/#19</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#19</guid>         
	  
      <description><![CDATA[Good read.  The difference between progressive enhancement and graceful degradation makes for a great interview question.

And since no one else has made the remark... some people are allergic to peanuts, but really enjoy JavaScript and CSS.  Cheers!]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: baoping wang</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#20</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#20</guid>         
	  
      <description><![CDATA[Good read.I can't stop translating it to chinese. here: http://lifesinger.org/blog/?p=298

Looking forward to the following articlesâ€¦]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: C Bird</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#21</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#21</guid>         
	  
      <description><![CDATA[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.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Tobias Sailer</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#22</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#22</guid>         
	  
      <description><![CDATA[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.
]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Stephen Down</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#23</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#23</guid>         
	  
      <description><![CDATA[bq. 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.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Stephen Down</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#24</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#24</guid>         
	  
      <description><![CDATA[Cameron Westland:

bq. 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!]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Steven Champeon</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#25</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#25</guid>         
	  
      <description><![CDATA[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.

]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Ian Goldby</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#26</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#26</guid>         
	  
      <description><![CDATA[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.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Maneet Puri</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#27</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#27</guid>         
	  
      <description><![CDATA[I loved the candy coat example! Couldnt have been more illustrative that that.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: piyush kotadiya</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#28</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#28</guid>         
	  
      <description><![CDATA[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]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Jonny Haynes</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P20/#29</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#29</guid>         
	  
      <description><![CDATA[Great article as always! But isn't this just common sense?]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Martin Smales</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#30</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#30</guid>         
	  
      <description><![CDATA[I want M&Ms;!]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Marty DeAngelo</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#31</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#31</guid>         
	  
      <description><![CDATA[I've been a proponent of PE for a while, and have gotten push back from developers who want to create for the 'latest and greatest' and _then_ look to fix any quirks later.  One of they key areas of this battle has been Flash.

I see Flash as being the printed "m" on the M&amp;M - it usually requires some JavaScript to work optimally, or at least there is very seldom Flash without JavaScript involved.  Just curious as to other thoughts about this - in the example presented, would Flash be the printed "m" or a second candy shell?]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Alex Stanford</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#32</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#32</guid>         
	  
      <description><![CDATA[Thank you for the wonderful article.  I had no real understanding of the difference that progressive enhancement intends to bring to the table until I read this article.  This article clearly portrays the advancements offered by such a development paradigm, and quickly offers up an understanding of it's fundamental differences.

Thanks again,
Alex]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Kendall Conrad</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#33</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#33</guid>         
	  
      <description><![CDATA[The article does miss explaining the 'M' printed on the candy. To me, this would represent the site's favicon.

I'm a fan of progressive enhancement as I use NoScript on Firefox and hate it when a site forces me to allow their JavaScript just to use the site's functionality, even though it's not needed. Sometimes I'll leave the site, but other ones I really need to use, so have to allow it.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: John K</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#34</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#34</guid>         
	  
      <description><![CDATA[I just don't see the difference between progressive enhancement and graceful degradation. To me it seems like progressive enhancement is just graceful degradation done right.

Can anyone please tell me which of the two the following scenario adheres to?

Someone builds a Javascript image gallery that loads all images, and hides the non selected images using Javascript+css. Anchors are used by Javascript to display the selected image and hide the previous selected image. The default action of the anchors are suppressed by Javascript.

If Javascript is disabled, the images are not hidden and all appear in the page. The anchors "href" is set to target the image, so when a certain anchor is clicked, the browser jumps to the appropriate image on the page.

Graceful degradation or progressive enhancement?]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Jeff Vdovjak</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#35</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#35</guid>         
	  
      <description><![CDATA[That was a quality article.  And a good kick in the pants.  Often when I go about CSS, even though I'm conscious to make it accessible and test it in older browsers, I focus on CSS being design - and I focus on design and plug the content in after.  But really, the content does need to be first.  Adding CSS while focusing on the content is a subtle but important shift in thinking.  Thanks for the thoughts...]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Pavel Kuts</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#36</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#36</guid>         
	  
      <description><![CDATA[In the past i was styling my H's nad A's and P's way before I put some content in the page. After that i started adding some content and then style it, then add some more content, and so on...

After I read your article it all clicked for me - I knew where I wanted  to go with the development of my HTML pages.

Now I put in all of my content, then I apply styles to it. It was remarkable to notice how much LESS ie-workarounds I had to apply to my code by doing so. Sometimes I even don't have to apply any. (those are the times when I'm grinning like a madman).

A great read! All three articles. Thank, you]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>

    <item>
      <title>Posted by: Paul Novitski</title>
	  
	      <link>http://www.alistapart.com/comments/understandingprogressiveenhancement/P30/#37</link>
      <guid>http://www.alistapart.com/comments/understandingprogressiveenhancement/#37</guid>         
	  
      <description><![CDATA["http://www.panic.com/coda/ â€“ A great example of progressive enhancement."

Yikes, I don't think so:

&lt;a href="[removed]ScrollArrow('right','toolbar','scroller','new-pane');"&gt;

It amazes me that folks still mark up their pages this way. No self-respecting GD/PE website would replace real hyperlinks with inline JavaScript in the markup. Instead, the HTML link should (re)load the page with the next chunk of content, and a linked JavaScript file would override that hyperlink with the ScrollArrow() behavior.]]></description>
      <dc:subject></dc:subject>
      <dc:date>2010-03-09T10:00:34+00:00</dc:date>
    </item>


    </channel>
</rss>