is everything we used to do wrong?

is everything

wrongwe used to do

This presentation is going tolook at some of our bestpractices from the past,

and what are consideredbest practices today.

First of all, an admission…

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

right vs wrongBest practices:

If we define one methodas the “right way” it often

implies that other methodsare wrong.

While there are definitely“bad practices”, there are

many situations wherethere are no clear right

or wrong solutions.

“Today, anything that’s fixed andunresponsive isn’t web design, it’s

something else. If you don’t embracethe inherent fluidity of the web, you’renot a web designer, you’re something

else.”

http://stuffandnonsense.co.uk/blog/about/i_dont_care_about_responsive_web_design/

things changeBest practices:

If history has taught usanything it’s that everything

changes over time.

Tables vs CSS

“My rule of thumb is Consistency,Consistency, Consistency... If CSS

works for a project, then I use it. If itdoesn’t look like it will, I use tables.”

http://www.raizlabs.com/blog/148/ten-reasons-why-css-sucks

Microformats

“The blog is neglected, there've been nonew formats promoted … none of us

work actively on it, … the mailing listsare deserted. It is an entirely

legitimate impression that the efforthas folded into irrelevance.”

http://microformats.org/wiki/events/2011-03-sxsw

The <i> element

The i element now represents a span oftext in an alternate voice or mood, or

otherwise offset from the normal prose ina manner indicating a different quality oftext, such as a taxonomic designation, a

technical term, an idiomatic phrase fromanother language, a thought, or a ship

name in Western texts.

http://www.w3.org/TR/html5-diff/

Um.. then there is myRemix07 presentation…

“Why separate your CSS? It’s easier tofind rules. More than one developer ata time. Files can be turned on or off as

needed.”

http://www.slideshare.net/maxdesign/modular-css

depend on skillsBest practices:

Best practices may be quitedifferent depending on the

skill area.

For example, best practicesin front end developmentmay be different from bestpractices in UX, SEO and

Social media…

depend on teamsBest practices:

Best practices may be quitedifferent depending on the

team you work with.

As an individual, you mayhave specific best practices.However, these may have tochange when working in a

team environment.

not techniquesoutcomes

Instead of talking about bestpractices as techniques, weshould probably focus on

outcomes.

Let’s take front enddevelopment (HTML, CSS,JavaScript) as an example:

What are some of ourdesired outcomes?

users come firstOutcome 1:

We should not do anythingthat makes the userexperience harder.

We should make sure oursites are accessible to

all users.

We should make sure oursites are accessible to

all devices.

We should make sure oursites are accessible

regardless of bandwidth.

develop efficientlyOutcome 2:

We should aim to developusing efficient methods,

to reduce overalldevelopment time.

We should aim to developusing methods that avoid

repetition.

maintainable,

scalable

Outcome 3:

We should aim to developusing practices that allow

easy maintenance.

We should aim to developusing practices that allowour sites to scale well

over time.

fast page loadOutcome 4:

We should aim to developsites so that pages load asquickly and efficiently as

possible.

backaward and

forward compatible

Outcome 5:

Does anyone else hate theterm “future proof”?

XHTML 1.0 was supposedto be a future-proof

language

We have to be careful notto leave our users behind

in the rush towardsthe future.

For example, JavaScriptbased solutions should be

built so that they failgracefully.

We should be careful aboutabandoning users with

older devices because wedon’t want to support them.

Some techniques that aid our

outcomes

So, here are somestrategies and techniquesthat are currently considered

“best practices”.

Be warned, thesemay not be considered

“best practices” in the future!

More importantly, these bestpractice techniques are

designed to help us achievesome key outcomes.

Reducingrepetition

1:CSS resets

CSS resets aim to removebrowser-specific styles, andthen build up from scratch -

so that each element willappear the same in all

browsers

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;

}

Strengths:Efficient developmentConsistency for teams

Weaknesses:lots of additional rewriting

2:CSS frameworks

CSS frameworks arepre-prepared libraries that

allow for easier, standards-compliant styling of web

page components.

Many frameworks focus onlayout grids, allowing

developers to pull in libraryclasses to build complex

layouts.

.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;}

Keep in mind you canalways roll your own

framework.

StrengthEfficient developmentLean, abstracted CSS

WeaknessesDesigns that don’t fitBloated frameworksPresentational class names

Maintainableand scalable

3:Object-oriented CSS

How many timesdoes your CSS file

mention H2 or“float: left”?

Do you ever findyourself stylingusing Firebug?

Object-oriented CSS stylesHTML “objects” or

“modules” with cleaner,more efficient CSS.

For all the hardcoredevelopers… yes, it’s not

really object-oriented.It’s just a name!

There is a strong chancethat you may be “doing it

wrong”, or could at least be“doing it better”.

How do we useObject Oriented CSS

Before starting your CSS,look at your layouts and

try to find patterns.

Are there aspects of thelayout that could be

abstracted into libraryitems?

Strengthslean, robust CSSeasier site maintenanceavoid repetitive CSSavoid specificity wars

Weaknessesadditional HTML classesnew mindset

Efficiency

4:Pre-processors

Pre-processors allow us touse variables in CSS filesand then parse them to

regular stylesheets.

There are many differentframeworks available:

• LESS • SASS

• Turbine • Switch CSS

• DtCSS • CSS Crush

Variables

@color1: red;@color2: green;@color3: blue;@color4: orange;@color5: brown;

#a { background: @color1; }

Minification

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;}#onea{color:green;}#two{background:green;-webkit-border-radius:30px;-moz-border-radius:30px;border-

Mixins

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

div { .border-radius(); }

PackingGzipping

Compiling

Strengthfaster developmentvariables!

Weaknessesdeep nestinginefficient CSSentirely new syntax

Deviceindependence

5:Responsive design

Until recently, people builtsites for desktop and/or

mobile only.

Responsive design isabout creating sites thatadapt to any device.

Problem 1:solving screen size

Ideally, we want to start witha single linear layout thatcan be viewed by any

device.

Then we gradually build aseries of advanced fluid

layouts on top, controlled bymedia queries or

JavaScript.

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

@media only screen and(min-width: 1000px){}

This means we can deliverentirely different layoutsbased on the viewport.

Problem 2:Solving bandwidth

issues

But what aboutimages and other rich

media?

Ideally, we should deliverlow end images and media

as the default.

Then we deliver larger,richer media for thosedevices with suitable

bandwidth.

Problem 3:content and context

Another problem we face isdetermining what types of

content should be deliveredto devices, and in whatcontext are people are

using the site.

It is not as simple asdelivering stripped back

content formobile devices and

rich content for desktops.

The reality is that these lasttwo problems are not solved

yet. But a change iscoming.

I think we are at a tippingpoint. Very soon, a major

site is going to crack thesethree problems and change

the way we build sites.

Final words?

A solution that seemsideal today may be

outdated tomorrow.

Focus on outcomes ratherthan using the latest

technique.

But most of allwe should have fun!

So, what are your best practices?