Many developers used to believe that class-free, lean markup and descendant selectors were the answer. Many developers still build websites for a single resolution, or a small range of devices. However, these practices are now being questioned. Where do we stand? What is best practice web development today? Russ Weakley will explore these topics and more... or possibly less...

1. is everything
we used to do
wrong

2. This presentation is going to
look at some of our best
practices from the past,
and what are considered
best practices today.

3. First of all, an admission…

4. I’m not a fan of the term
“best practice” any more.

5. Best practices:
right vs w rong

6. If we define one method
as the “right way” it often
implies that other methods
are wrong.

7. While there are definitely
“bad practices”, there are
many situations where
there are no clear right
or wrong solutions.

8. “Today, anything that’s fixed and
unresponsive isn’t web design, it’s
something else. If you don’t embrace
the inherent fluidity of the web, you’re
not a web designer, you’re something
else.”
http://stuffandnonsense.co.uk/blog/about/i_dont_care_about_responsive_web_
design/

9. Best practices:
things change

10. If history has taught us
anything it’s that everything
changes over time.

11. Tables vs CSS

12. “My rule of thumb is Consistency,
Consistency, Consistency... If CSS
works for a project, then I use it. If it
doesn’t look like it will, I use tables.”
http://www.raizlabs.com/blog/148/ten-reasons-why-css-sucks

13. Microformats

14. “The blog is neglected, there've been no
new formats promoted … none of us
work actively on it, … the mailing lists
are deserted. It is an entirely
legitimate impression that the effort
has folded into irrelevance.”
http://microformats.org/wiki/events/2011-03-sxsw

15. The <i> element

16. The i element now represents a span of
text in an alternate voice or mood, or
otherwise offset from the normal prose in
a manner indicating a different quality of
text, such as a taxonomic designation, a
technical term, an idiomatic phrase from
another language, a thought, or a ship
name in Western texts.
http://www.w3.org/TR/html5-diff/

17. Um.. then there is my
Remix07 presentation…

18. “Why separate your CSS? It’s easier to
find rules. More than one developer at
a time. Files can be turned on or off as
needed.”
http://www.slideshare.net/maxdesign/modular-css

19. Best practices:
pend on skills
de

20. Best practices may be quite
different depending on the
skill area.

21. For example, best practices
in front end development
may be different from best
practices in UX, SEO and
Social media…

22. Best practices:
e pend on te ams
d

23. Best practices may be quite
different depending on the
team you work with.

24. As an individual, you may
have specific best practices.
However, these may have to
change when working in a
team environment.

25. outcomes
not techniques

26. Instead of talking about best
practices as techniques, we
should probably focus on
outcomes.

27. Let’s take front end
development (HTML, CSS,
JavaScript) as an example:

28. What are some of our
desired outcomes?

29. Outcome 1:
u sers come first

30. We should not do anything
that makes the user
experience harder.

31. We should make sure our
sites are accessible to
all users.

32. We should make sure our
sites are accessible to
all devices.

33. We should make sure our
sites are accessible
regardless of bandwidth.

34. Outcome 2:
elop efficiently
dev

35. We should aim to develop
using efficient methods,
to reduce overall
development time.

36. We should aim to develop
using methods that avoid
repetition.

37. Outcome 3:
m ain taina ble,
s cal able

38. We should aim to develop
using practices that allow
easy maintenance.

39. We should aim to develop
using practices that allow
our sites to scale well
over time.

40. Outcome 4:
fast page load

41. We should aim to develop
sites so that pages load as
quickly and efficiently as
possible.

42. Outcome 5:
backawar d and
comp atible
forward

43. Does anyone else hate the
term “future proof”?

44. XHTML 1.0 was supposed
to be a future-proof
language

45. We have to be careful not
to leave our users behind
in the rush towards
the future.

46. For example, JavaScript
based solutions should be
built so that they fail
gracefully.

47. We should be careful about
abandoning users with
older devices because we
don’t want to support them.

48. Some techniques
that aid our
outcomes

49. So, here are some
strategies and techniques
that are currently considered
“best practices”.

50. Be warned, these
may not be considered
“best practices” in the future!

51. More importantly, these best
practice techniques are
designed to help us achieve
some key outcomes.

52. Reducing
repetition

53. 1:
CSS resets

54. CSS resets aim to remove
browser-specific styles, and
then build up from scratch -
so that each element will
appear the same in all
browsers

55. html,body,div,span,applet,object,iframe,h1,h2,
h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,
address,big,cite,code,del,dfn,em,img,ins,kbd,q,
s,samp,small,strike,strong,sub,sup,tt,var,b,u,
i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,
legend,table,caption,tbody,tfoot,thead,tr,th,
td,article,aside,canvas,details,embed,figure,
figcaption,footer,header,hgroup,menu,nav,
output,ruby,section,summary,time,mark,audio,
video
{
margin:0;
padding:0;
border:0;
font-size:100%;
font: inherit;
vertical-align: baseline;
}

56. Strengths:
Efficient development
Consistency for teams
Weaknesses:
lots of additional rewriting

57. 2:
CSS frameworks

58. CSS frameworks are
pre-prepared libraries that
allow for easier, standards-
compliant styling of web
page components.

59. Many frameworks focus on
layout grids, allowing
developers to pull in library
classes to build complex
layouts.

60. .column, .span-1, .span-2,
.span-3, .span-4, .span-5,
.span-6, .span-7, .span-8,
.span-9, .span-10, .span-11,
.span-12, .span-13, .span-14,
.span-15, .span-16, .span-17,
.span-18, .span-19, .span-20,
.span-21, .span-22, .span-23,
.span-24 {float:left;margin-
right:10px;}

61. Keep in mind you can
always roll your own
framework.

62. Strength
Efficient development
Lean, abstracted CSS
Weaknesses
Designs that don’t fit
Bloated frameworks
Presentational class names

63. Maintainable
and scalable

64. 3:
Object-oriented CSS

65. How many times
does your CSS file
mention H2 or
“float: left”?

66. Do you ever find
yourself styling
using Firebug?

67. Object-oriented CSS styles
HTML “objects” or
“modules” with cleaner,
more efficient CSS.

68. For all the hardcore
developers… yes, it’s not
really object-oriented.
It’s just a name!

69. There is a strong chance
that you may be “doing it
wrong”, or could at least be
“doing it better”.

70. How do we use
Object Oriented CSS

71. Before starting your CSS,
look at your layouts and
try to find patterns.

72. Are there aspects of the
layout that could be
abstracted into library
items?

73. Strengths
lean, robust CSS
easier site maintenance
avoid repetitive CSS
avoid specificity wars
Weaknesses
additional HTML classes
new mindset

74. Efficiency

75. 4:
Pre-processors

76. Pre-processors allow us to
use variables in CSS files
and then parse them to
regular stylesheets.

77. There are many different
frameworks available:
• LESS
• SASS
• Turbine
• Switch CSS
• DtCSS
• CSS Crush

78. Variables

79. @color1: red;
@color2: green;
@color3: blue;
@color4: orange;
@color5: brown;
#a { background: @color1; }

80. Minification

81. div{width:200px;height:200px;
-webkit-border-radius:10px;-
moz-border-
radius:10px;border-
radius:10px;}
#one{background:red;-webkit-
border-radius:20px;-moz-
border-radius:20px;border-
radius:20px;}#one
a{color:green;}
#two{background:green;-

82. Mixins

83. .border-radius(@radius: 5px)
{
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
border-radius: @radius;
}
div { .border-radius(); }

84. Packing
Gzipping
Compiling

85. Strength
faster development
variables!
Weaknesses
deep nesting
inefficient CSS
entirely new syntax

86. Device
independence

87. 5:
Responsive design

88. Until recently, people built
sites for desktop and/or
mobile only.

89. Responsive design is
about creating sites that
adapt to any device.

90. Problem 1:
solving screen size

91. Ideally, we want to start with
a single linear layout that
can be viewed by any
device.

92. Then we gradually build a
series of advanced fluid
layouts on top, controlled by
media queries or
JavaScript.

93. @media only screen and
(min-width: 800px) and
(max-width: 999px)
{
}
@media only screen and
(min-width: 1000px)
{
}

94. This means we can deliver
entirely different layouts
based on the viewport.

95. Problem 2:
Solving bandwidth
issues

96. But what about
images and other rich
media?

97. Ideally, we should deliver
low end images and media
as the default.

98. Then we deliver larger,
richer media for those
devices with suitable
bandwidth.

99. Problem 3:
content and context

100. Another problem we face is
determining what types of
content should be delivered
to devices, and in what
context are people are
using the site.

101. It is not as simple as
delivering stripped back
content for
mobile devices and
rich content for desktops.

102. The reality is that these last
two problems are not solved
yet. But a change is
coming.

103. I think we are at a tipping
point. Very soon, a major
site is going to crack these
three problems and change
the way we build sites.

104. Final words?

105. A solution that seems
ideal today may be
outdated tomorrow.

106. Focus on outcomes rather
than using the latest
technique.

107. But most of all
we should have fun!

108. So, what are your
best practices?