The document emphasizes the importance of creating user-friendly web solutions rather than focusing on the technology behind them. It critiques the tendency of developers to become overly enamored with specific technologies, advocating for a simpler, progressive enhancement approach to web development. Key challenges such as security, hardware access, and accessibility in HTML5 and CSS3 are highlighted, along with humorous commentary on dealing with legacy issues like Internet Explorer 6.

1. Progressing
and enhancing.
Chris&an Heilmann
SWDC, Stockholm, Sweden, June 2010

2. Our job as web
developers is to
create working
solutions.

3. End users should
not have to care
what technology we
used.

4. All they should get
is an interface that
works and helps
them reach their
goal.

5. They need and want
to fulfil a task - not
marvel at our
craftsmanship.

7. The main problem is
that we love
marvelling at our
craftsmanship.

8. We tend to get
terribly excited
about things in our
little world.

9. And play with them
to push the
envelope.

11. We measure our
successes by how
much we achieve in
our own world...

12. ...rather than how
many end users we
made happy.

13. This also leads to an
amazing amount of
truisms floating
around.

14. “Ev
ery
Java bod
Scr yh
frea ipt as
ks t - on
urn ly
it of
f.”

15. d
n !”
g a s
ra day
d e
t es
ec h
p
ex es t
le ac
op rf
P e
“
in te
d r op

16. ns t he
m ea e
i Pa d a sw
“ T he de si gn
fw eb
en d o
ow i t.”
kn

17. “Th
easi is c
an b
ly w e do
ith ne
jQu
ery”

18. And also totally
wrong statements.

19. “My
favou
HTM rite p
art of
L5 is
locati geo
on!”

20. erfu lp art
ost pow
“T he m sitions
S3 is t ran
of CS tion s.”
and an ima

21. To console
ourselves to see
that we are right,
we have statistics.

22. But three out of five
people know that
76.3% of statistics
are made up on the
spot.

23. Let me tell you what
happens when you
give out truisms like
that.

24. Every time you say
things like that...
This dog will disapprove... ...and these will not get fed.

25. The biggest fallacy
in our ways is to
pick a pet
technology...

26. ...and then do
frigging everything
in it!

27. Ligh
tbox
in pu
re CS
S!

28. look like
hin gs that
T ows 95
ba dW ind
Can vas
nsa vers in
s cree scr ipt!
and Java
Now with fr
ee 100% me
mory use!

29. Even if we don’t use
the technology - we
call it a CSS3 or
HTML5 solution.

30. We arrived at:
DHTML5
With thanks to Scott Schiller

31. It is ironic that we
don’t plan for non-
JS environments
but for IE6
fallbacks!

32. With the fallback
being expression()
and IE filters.

33. Which did almost
everything WebKit
extensions do now.

34. But without style
and on much slower
hardware.

35. expression() and
filters are evil and
have to die!

36. The main problem is
our approach.

37. We have to
emancipate
ourselves from the
idea of the interface
as the starting
point.

38. If we build the
simplest solution
first we can enhance
it to whatever we
want.

39. Including mobile!

40. A lot of “using
newest technology”
is a lame excuse for
not architecting our
solutions.

41. There are real issues
HTML5 and CSS3
need to solve:
★ Security
★ Hardware Access (Camera, Location, 3D
accelleration)
★ Native rich controls
★ Layout
★ Internationalisation
★ Accessibility
★ Rich Media (video, audio)

42. For now, your only
chance to build
good web apps is
progressive
enhancement.

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

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

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

47. Both these solutions
started the same
way.

50. Getting data from a
web service on the
server and
rendering out HTML
for CSS and JS to
access.

51. If you want to build
things for the web
you will need to use
all these
technologies.

52. Otherwise you are
reliant on software
vendors - and that
is a bad idea.

53. We did this for IE6
and that is why
there are so many
bad web
applications out
there.

54. It seems to be
impossible to get
rid of IE6 because
of that - but I have a
solution!

55. The Amelie approach
to the IE6 problem.

56. Despite of what I
said earlier, there is
one filter we can
use to solve one of
our problems.

57. One of the most
pointless IE filters
ever created is
blur().
http://msdn.microsoft.com/en-us/library/
ms532979%28VS.85%29.aspx

58. No filter
Slight filter

59. Applied randomly
every few seconds
with a slight blur
this can be
effective.

60. If we build the
simplest solution
first we can enhance
it to whatever we
want.

61. http://www.youtube.com/watch?v=pLVuRX-iZbQ

62. We leave this in our
code for a few
months.

63. Maybe persuade
Google to add it to
AdSense!

64. When people
complain, we say
that our code is bug
free - it is a mystery.

65. Then we get some
“experts” to tell the
press that it might
be software fatigue.

66. =

67. That way we turn
IE6 from a technical
problem to a health
and safety issue!

68. And corporate HR
carries more clout
than corporate IT!

69. If we all
work
together,
we can
win this!
http://icant.co.uk/ie6-amelie/

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