Write less - achieve more
Understanding
progressive
enhancement with YUI
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!
http://www.youtube.com/watch?v=CwsDKaalgq8&
http://www.youtube.com/watch?v=QiuT0y0KR6I
Easy YouTube
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 advantag...
It is not straightforward for HMG
departments to upgrade IE versions
on their systems.  Upgrading these
systems to IE8 can...
To test all the web applications
currently used by HMG departments
can take months at significant
potential cost to the tax...
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 ...
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://github.com/codepo8/warwickshire
http://isithackday.com/demos/warwickshire/
http://www.youtube.com/watch?v=_uAOyzw50...
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://github.com/codepo8/flickrcollector
http://isithackday.com/hacks/flickrcollector/
http://www.youtube.com/watch?v=i_1...
http://github.com/codepo8/flickrcollector
http://isithackday.com/hacks/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...
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/c...
Filter inputs for
nasties and include
the rules.
If the form has not
been submitted,
include the form
code.
Otherwise loop through the
rules and check the data
that was sent against them.
this is like /pattern/.test($(name).value)
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...
Load the IO and Node
module.
Define the configuration
for the Ajax call.
On submission of the form
load the validate.php f...
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.
type=”range”
type=”date”
type=”color”
type=”file”
<datalist>
Re-use of learnings.
CSS3
Animation
Transition
and
Capability based
loading = win!
The future of web
apps is being
forged right now.
HTML5
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
http://developer-evangelism.com
http://twitter.com/codepo8
Thanks!
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Understanding progressive enhancement - yuiconf2010
Upcoming SlideShare
Loading in …5
×

Understanding progressive enhancement - yuiconf2010

9,930 views

Published on

Understanding progressive enhancement - yuiconf2010

  1. Write less - achieve more Understanding progressive enhancement with YUI
  2. Progressive enhancement gets a bad rep these days.
  3. The reason is not that it is a bad idea.
  4. The reason is that it is misunderstood.
  5. Walled-off environments lead to progressive enhancement criticism.
  6. A Chrome extension will never have to work in IE6 - there is no point in that.
  7. iPad/iPhone/Air apps are much easier than building a web app.
  8. Staying in the comfort zone.
  9. Peripheral vision.
  10. http://everytimezone.com/
  11. Technology annoyances are as much annoyances as physical ones.
  12. HTML5 does not mean building apps for iPad, iPhone and Android.
  13. It is very easy to fall in this trap as developers.
  14. Everybody has JavaScript these days “ “
  15. I don’t really care about the numbers.
  16. To me, it is about celebrating the power of the web and software.
  17. The physical world can be a real pain.
  18. The most powerful tool of code is the if(){} statement.
  19. Take that “if” and make it part of your approach to development...
  20. ...and you have progressive enhancement.
  21. Add after you tested for it.
  22. That way you never have the need to degrade gracefully.
  23. Building for the web means open development.
  24. The web is a scary place.
  25. But it is so worth it!
  26. http://www.youtube.com/watch?v=CwsDKaalgq8& http://www.youtube.com/watch?v=QiuT0y0KR6I Easy YouTube
  27. You can leave now - I don’t need you any longer to watch my videos! “ “
  28. A constantly upgrading web?
  29. IE6+Large Organisations=BFF http://www.hmg.gov.uk/epetition-responses/petition-view.aspx?epref=ie6upgrade
  30. 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.
  31. 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.
  32. To test all the web applications currently used by HMG departments can take months at significant 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 firewalls and malware scanning software, to further protect public sector internet users.
  33. And this is why we need progressive enhancement.
  34. Which is not “making it work for IE6”.
  35. Instead it is “test for support before you apply” http://www.modernizr.com/ http://github.com/phiggins42/has.js
  36. Let’s go through a few examples of how progressive enhancement works.
  37. Pure JS environments.
  38. http://10k.aneventapart.com/Entry/185 http://github.com/codepo8/worldinfo
  39. Buttons?
  40. ★ There is no real navigation happening here. ★ Everything is dependent on JS. ★ This is what buttons are for. ★ And they are keyboard accessible.
  41. Speeding up the process for the next visit.
  42. Leaving fairyland and moving to the web...
  43. A very common approach to PE...
  44. Progressive enhancement by using a single page as the data container.
  45. http://github.com/codepo8/warwickshire http://isithackday.com/demos/warwickshire/ http://www.youtube.com/watch?v=_uAOyzw50PY
  46. Pro: Always works - it is an HTML document Con: Can result in huge sites (but gzip helps)
  47. Another approach: Using the backend as a simple API.
  48. http://github.com/codepo8/flickrcollector http://isithackday.com/hacks/flickrcollector/ http://www.youtube.com/watch?v=i_1sVnNkN2M
  49. http://github.com/codepo8/flickrcollector http://isithackday.com/hacks/flickrcollector/
  50. Write the app as a simple form submit in PHP...
  51. Then return chunks of HTML according to the parameters that came in.
  52. Override the requests with Ajax calls.
  53. You maintain your whole app on the server and can monitor and cache like heck.
  54. And you still use the goodness that is JavaScript on top of that.
  55. Pro: Re-use of server includes as APIs possible. Least amount of JS and HTML generation in JS. Con: Needs server component knowledge
  56. Every app works as a server-client connection in some way.
  57. The data has to come from some place.
  58. The myth of client- side security.
  59. Every JS developer sooner or later writes a form validator.
  60. This is always the killer argument of enemies of progressive enhancement.
  61. I spend a lot of time doing form validation in JavaScript - why should I repeat the same on the server side? “ “
  62. Because there is no security in JavaScript!
  63. If all you do is validate in JS, attackers will have a field day with your server.
  64. Besides, there is no need to repeat validation rules.
  65. That way you validate on the server and you can use the same rules for your JS...
  66. Form validation scripts are annoying.
  67. You need to access the right parts, read and write from the DOM, change styles and and and...
  68. You can leave it all to the server and still save your users a full page reload.
  69. Request type switching is the answer.
  70. JavaScript libraries add a special footprint to the server request when calling content via Ajax.
  71. You can use this to send content to Ajax requests and other content to normal requests.
  72. 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
  73. Filter inputs for nasties and include the rules.
  74. If the form has not been submitted, include the form code.
  75. Otherwise loop through the rules and check the data that was sent against them. this is like /pattern/.test($(name).value)
  76. If there was an error - show the form again. Otherwise say thanks.
  77. The form itself is a simple HTML form doing all the dynamic rendering with PHP...
  78. Check for the error array and if there is an error, show it. Otherwise show a * to indicate required field.
  79. Check if the form was sent via Ajax - if not, render the form element.
  80. If there was an error, say so. At the field show the error or the * SPAN.
  81. And all you then need to do in JavaScript is to override the form submission.
  82. And instead replace the innerHTML of the form on every submit.
  83. An example using YUI3...
  84. Load the IO and Node module. Define the configuration for the Ajax call. On submission of the form load the validate.php file with the config and don’t send off the form.
  85. If the Ajax call was a success, replace the innerHTML of the form with the HTML returned from validate.php
  86. In addition to that, focus on the first element with an error message - this helps with assistive technology.
  87. If the Ajax call failed, send the form.
  88. Subscribe to the Ajax events.
  89. Build what works for everybody and then enhance.
  90. http://uk-house-prices.com/
  91. http://icant.co.uk/csscharts/
  92. For a lot of new developers, this looks like extra effort.
  93. Instead we produce low quality fallbacks.
  94. This is not the web I want people to get!
  95. Bah! PHP...
  96. Progressive Enhancement is a huge part of the YUI philosophy.
  97. http://www.yuiblog.com/blog/2010/09/29/video-glass-node/
  98. Today’s widgets are already tomorrow’s native controls.
  99. type=”range” type=”date” type=”color” type=”file” <datalist>
  100. Re-use of learnings.
  101. CSS3 Animation Transition and
  102. Capability based loading = win!
  103. The future of web apps is being forged right now.
  104. HTML5
  105. Be part of the movement for a better web for all.
  106. HTML5 means moving from hacks to web applications.
  107. So let’s build a working web for all.
  108. Come and talk to us, to Google, to Apple, to Mozilla, to Opera, to Microsoft... Your input matters!
  109. Christian Heilmann http://wait-till-i.com http://developer-evangelism.com http://twitter.com/codepo8 Thanks!

×