Understanding progressive enhancement - yuiconf2010

Understanding progressive enhancement with YUI Write less - achieve more

Progressive enhancement gets a bad rep these days.

The reason is not that it is a bad idea.

The reason is that it is misunderstood.

Walled-off environments lead to progressive enhancement criticism.

A Chrome extension will never have to work in IE6 - there is no point in that.

iPad/iPhone/Air apps are much easier than building a web app.

Staying in the comfort zone.

Peripheral vision.

http://everytimezone.com/

Technology annoyances are as much annoyances as physical ones.

HTML5 does not mean building apps for iPad, iPhone and Android.

It is very easy to fall in this trap as developers.

“ Everybody has JavaScript these days “

I don’t really care about the numbers.

To me, it is about celebrating the power of the web and software.

The physical world can be a real pain.

The most powerful tool of code is the if(){} statement.

Take that “if” and make it part of your approach to development...

...and you have progressive enhancement.

Add after you tested for it.

That way you never have the need to degrade gracefully.

Building for the web means open development.

The web is a scary place.

But it is so worth it!

Easy YouTube http://www.youtube.com/watch?v=CwsDKaalgq8& http://www.youtube.com/watch?v=QiuT0y0KR6I

“ You can leave now - I don’t need you any longer to watch my videos! “

A constantly upgrading web?

IE6+Large Organisations=BFF http://www.hmg.gov.uk/epetition-responses/petition-view.aspx?epref=ie6upgrade

Complex software will always have vulnerabilities and motivated adversaries will always work to discover and take advantage of them. There is no evidence that upgrading away from the latest fully patched versions of Internet Explorer to other browsers will make users more secure.

It is not straightforward for HMG departments to upgrade IE versions on their systems. Upgrading these systems to IE8 can be a very large operation, taking weeks to test and roll out to all users.

To test all the web applications currently used by HMG departments can take months at signiﬁcant potential cost to the taxpayer. It is therefore more cost effective in many cases to continue to use IE6 and rely on other measures, such as ﬁrewalls and malware scanning software, to further protect public sector internet users.

And this is why we need progressive enhancement.

Which is not “making it work for IE6”.

Instead it is “test for support before you apply” http://www.modernizr.com/ http://github.com/phiggins42/has.js

Let’s go through a few examples of how progressive enhancement works.

Pure JS environments.

http://10k.aneventapart.com/Entry/185 http://github.com/codepo8/worldinfo

Buttons?

★ There is no real navigation happening here. ★ Everything is dependent on JS. ★ This is what buttons are for. ★ And they are keyboard accessible.

Speeding up the process for the next visit.

Leaving fairyland and moving to the web...

A very common approach to PE...

Progressive enhancement by using a single page as the data container.

http://isithackday.com/demos/warwickshire/ http://github.com/codepo8/warwickshire http://www.youtube.com/watch?v=_uAOyzw50PY

Pro: Always works - it is an HTML document Con: Can result in huge sites (but gzip helps)

Another approach: Using the backend as a simple API.

http://www.youtube.com/watch?v=i_1sVnNkN2M http://isithackday.com/hacks/flickrcollector/ http://github.com/codepo8/flickrcollector

http://isithackday.com/hacks/flickrcollector/ http://github.com/codepo8/flickrcollector

Write the app as a simple form submit in PHP...

Then return chunks of HTML according to the parameters that came in.

Override the requests with Ajax calls.

You maintain your whole app on the server and can monitor and cache like heck.

And you still use the goodness that is JavaScript on top of that.

Pro: Re-use of server includes as APIs possible. Least amount of JS and HTML generation in JS. Con: Needs server component knowledge

Every app works as a server-client connection in some way.

The data has to come from some place.

The myth of client- side security.

Every JS developer sooner or later writes a form validator.

This is always the killer argument of enemies of progressive enhancement.

“I spend a lot of time doing form validation in JavaScript - why should I repeat the same on the server side? “

Because there is no security in JavaScript!

If all you do is validate in JS, attackers will have a field day with your server.

Besides, there is no need to repeat validation rules.

That way you validate on the server and you can use the same rules for your JS...

Form validation scripts are annoying.

You need to access the right parts, read and write from the DOM, change styles and and and...

You can leave it all to the server and still save your users a full page reload.

Request type switching is the answer.

JavaScript libraries add a special footprint to the server request when calling content via Ajax.

You can use this to send content to Ajax requests and other content to normal requests.

You can use this to render a form completely server side and just send a string back for each request. http://github.com/codepo8/validationdemo

Filter inputs for nasties and include the rules.

If the form has not been submitted, include the form code.

this is like /pattern/.test($(name).value) Otherwise loop through the rules and check the data that was sent against them.

If there was an error - show the form again. Otherwise say thanks.

The form itself is a simple HTML form doing all the dynamic rendering with PHP...

Check for the error array and if there is an error, show it. Otherwise show a * to indicate required field.

Check if the form was sent via Ajax - if not, render the form element.

If there was an error, say so. At the field show the error or the * SPAN.

And all you then need to do in JavaScript is to override the form submission.

And instead replace the innerHTML of the form on every submit.

An example using YUI3...

On submission of the form load the validate.php file with the config and don’t send off the form. Load the IO and Node module. Define the configuration for the Ajax call.

If the Ajax call was a success, replace the innerHTML of the form with the HTML returned from validate.php

In addition to that, focus on the first element with an error message - this helps with assistive technology.

If the Ajax call failed, send the form.

Subscribe to the Ajax events.

Build what works for everybody and then enhance.

http://uk-house-prices.com/

http://icant.co.uk/csscharts/

For a lot of new developers, this looks like extra effort.

Instead we produce low quality fallbacks.

This is not the web I want people to get!

Bah! PHP...

Progressive Enhancement is a huge part of the YUI philosophy.

http://www.yuiblog.com/blog/2010/09/29/video-glass-node/

Today’s widgets are already tomorrow’s native controls.

<datalist> type=”color” type=”range” type=”file” type=”date”

Re-use of learnings.

CSS3 Animation and Transition

Capability based loading = win!

The future of web apps is being forged right now.

Be part of the movement for a better web for all.

HTML5 means moving from hacks to web applications.

So let’s build a working web for all.

Come and talk to us, to Google, to Apple, to Mozilla, to Opera, to Microsoft... Your input matters!

Christian Heilmann http://wait-till-i.com Thanks! http://developer-evangelism.com http://twitter.com/codepo8

http://www.wait-till-i.com	207
http://christianheilmann.com	112
http://lanyrd.com	22
http://static.slidesharecdn.com	4
http://www.longseason.co.cc	4
http://www.hillowner.com	2
http://www.netvibes.com	1
http://icant.co.uk	1
http://localhost.web2py.es:81	1

Understanding progressive enhancement - yuiconf2010

by Christian Heilmann on Nov 09, 2010

Accessibility

Upload Details

Usage Rights

9 Embeds 354

Statistics

Understanding progressive enhancement - yuiconf2010 Presentation Transcript