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.

11. http://everytimezone.com/

12. Technology
annoyances are as
much annoyances as
physical ones.

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

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

16. Everybody has JavaScript these
days
“
“

17. I don’t really care
about the numbers.

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

19. The physical world
can be a real pain.

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

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

24. ...and you have
progressive
enhancement.

25. Add after you
tested for it.

26. That way you never
have the need to
degrade gracefully.

27. Building for the web
means open
development.

29. The web is a scary
place.

30. But it is so worth it!

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

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

33. A constantly
upgrading web?

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

35. 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.

36. 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.

37. 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.

39. And this is why we
need progressive
enhancement.

40. Which is not
“making it work for
IE6”.

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

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

43. Pure JS
environments.

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

48. Buttons?

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

50. Speeding up the
process for the next
visit.

52. Leaving fairyland
and moving to the
web...

53. A very common
approach to PE...

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

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

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

58. Another approach:
Using the backend
as a simple API.

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

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

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

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

66. Override the
requests with Ajax
calls.

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

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

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

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

72. The data has to
come from some
place.

73. The myth of client-
side security.

74. Every JS developer
sooner or later
writes a form
validator.

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

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

77. Because there is no
security in
JavaScript!

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

79. Besides, there is no
need to repeat
validation rules.

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

84. Form validation
scripts are
annoying.

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

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

87. Request type
switching is the
answer.

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

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

92. 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

94. Filter inputs for
nasties and include
the rules.

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

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

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

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

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

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

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

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

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

105. An example using
YUI3...

106. 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.

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

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

109. If the Ajax call failed, send
the form.

110. Subscribe to the Ajax
events.

111. Build what works
for everybody and
then enhance.

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

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

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

115. Instead we produce low
quality fallbacks.

116. This is not the web I
want people to get!

117. Bah! PHP...

118. Progressive
Enhancement is a
huge part of the YUI
philosophy.

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

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

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

123. Re-use of learnings.

124. CSS3
Animation
Transition
and

126. Capability based
loading = win!

127. The future of web
apps is being
forged right now.

128. HTML5

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

131. HTML5 means
moving from hacks
to web applications.

132. So let’s build a
working web for all.

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

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