Slide 1
Slide 1 text
Architecting
Scalable CSS
Harry Roberts
Industry Conf – April, 2013
Slide 2
Slide 2 text
No content
Slide 3
Slide 3 text
Planning and writing
CSS in a way that will
allow it to scale,
similar to how an
architect might.
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
Who?!
•Harry Roberts
•Developer, front-end architect
•Not a police-murdering serial killer
•@csswizardry
•csswizardry.com
Slide 6
Slide 6 text
Seriously.
Slide 7
Slide 7 text
Who?!
•Harry Roberts
•Developer, front-end architect
•Not a police-murdering serial killer
•@csswizardry
•csswizardry.com
Slide 8
Slide 8 text
No content
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
Break it down!
Slide 11
Slide 11 text
LEGO
•Break code into the smallest little
blocks possible.
•Lots of blocks are far more versatile
than whole structures.
•Blocks can be combined with all other
types of block.
Slide 12
Slide 12 text
Failing to plan is
planning to fail.
— The same people who say ‘I told you so’
Slide 13
Slide 13 text
The house
that devs built
Slide 14
Slide 14 text
•Built in months, lasts for years.
•Numerous workers with different skills.
•Built by some, maintained by others.
House vs. website
Slide 15
Slide 15 text
•Foundations: reset, normalize.css
•Structure: grid system, layout
•Fittings: components, modules
•Decoration: design, ‘look-and-feel’
•Ornaments: theming, takeovers, skins
House vs. website
Slide 16
Slide 16 text
No content
Slide 17
Slide 17 text
css/
vars.scss
aluminium/
aluminium.scss
generic/
base/
objects/
gui/
style.scss
Slide 18
Slide 18 text
•Jonathan Snook
•@snookca
•smacss.com
•Promo: YOUREAWIZARDHARRY
SMACSS
Slide 19
Slide 19 text
No content
Slide 20
Slide 20 text
•Everything should do one thing, one
thing only, and one thing well.
•Allows for greater amounts of
combinations of smaller things.
•The basis of Unix.
Single responsibility
principle
Slide 21
Slide 21 text
# Find files in current dir with
# png in the title and reverse
# sort them by month.
$ ls | grep "png" | sort -Mr
Slide 22
Slide 22 text
# List all running processes and
# search them for "ssh".
$ ps -ax | grep "ssh"
Slide 23
Slide 23 text
•Lots of smaller, single instances.
•Bits can be added or omitted with ease.
•Easily combined for different results.
LEGOSubwayHouse
Slide 24
Slide 24 text
- ...
- ...
Slide 25
Slide 25 text
•If a thing does three separate jobs, it
needs three separate hooks.
•Allows you to stay more granular.
•Build more combinations more quickly.
•Keeps CSS’ size down.
More classes
Slide 26
Slide 26 text
More classes means
more to maintain.
— Every developer everywhere ever
Slide 27
Slide 27 text
About that…
Slide 28
Slide 28 text
•Changing a dozen classes in your HTML
is a lot simpler (and nicer) than picking
apart a tangled stylesheet.
•Use tools (command line (grep, sed,
etc.), global find and replace, etc.) to
help you.
1. HTML is simple
Slide 29
Slide 29 text
•Why are things repeated so much
anyway?
•DRY out your HTML as well as your CSS.
2. DRY your markup
Slide 30
Slide 30 text
3. It’s your job.
Slide 31
Slide 31 text
•As a developer you are expected to
maintain and work with code; why get
so scared by the idea?
•Embrace ways to make it easier.
•Split the load between HTML and CSS.
It’s your job…
Slide 32
Slide 32 text
•Keep it low.
•Always.
•Classes are ideally suited to the
granularity of SRP.
•No IDs.
Specificity
Slide 33
Slide 33 text
But IDs mean that
I can spot unique
elements in HTML!
— A lot of developers, still
Slide 34
Slide 34 text
Slide 35
Slide 35 text
Music is the space
between the notes.
— Claude Debussy
Slide 36
Slide 36 text
CSS is all the same
.foo{
float:left;
color:#BADA55;
border:0 solid #C0FFEE;
border-width:1px 0;
}
Slide 37
Slide 37 text
}…{
Slide 38
Slide 38 text
.foo{
/* Whatever... */
}
/* Important bits! */
.bar{
/* Booooring! */
}
Slide 39
Slide 39 text
•Block: a discrete component
•Element: a part of that component
•Modifier: a variation of that component
BEM
Slide 40
Slide 40 text
BEM
.person{}
.person__hand{}
.person--female{}
Slide 41
Slide 41 text
Slide 42
Slide 42 text
Slide 43
Slide 43 text
•Split code into smaller chunks.
•Quickly reorder and rejig things.
•Easily [ex|in]clude things.
•Make code DRYer.
Preprocessors
Slide 44
Slide 44 text
•Plenty of them.
•Document anything that isn’t obvious
from the code alone.
•Explain what, how and why.
Comments
Slide 45
Slide 45 text
/**
* Comment title
*
* Longer description of the
* code goes here.
*
* 1. Contain floats.
*/
.foo{
overflow:hidden; /* [1] */
}
Slide 46
Slide 46 text
Clean house,
clean mind.
— Mothers
Slide 47
Slide 47 text
Keeping clean
•Consistent formatting.
•Loads of whitespace.
•Plenty of comments.
•You can make bad code look good.
Slide 48
Slide 48 text
.foo{
color: red; background:green;
display:block ;
-webkit-border-radius:4px;
-moz-border-radius:4px;
border-radius:4px;
}
Slide 49
Slide 49 text
.foo{
color:red;
background:green;
display:block;
-webkit-border-radius:4px;
-moz-border-radius:4px;
border-radius:4px;
}
Slide 50
Slide 50 text
Housekeeping
•Factor in tidy-up and refactor time to
any feature estimates.
•Regularly create tech tasks to maintain
and tidy up your codebase.
•It’s not just about shipping new code,
it’s also about looking after the code
you already have.
Slide 51
Slide 51 text
shame.css
•Hacks
•Short term fixes
•Tech debt
•$ git blame shame.css
Slide 52
Slide 52 text
Don’t stress
•Nothing is 100% right first time.
•Things get worse as time progresses.
•You can’t do better than your best.
•Stop caring too much; it’s just code.
Slide 53
Slide 53 text
tl;dr
•One job, one job only, one well.
•Keep specificity low.
•Run a tight ship.
•Keep on keeping on.
Slide 54
Slide 54 text
Fin.
•Harry Roberts
•smacss.com | bem.info
•csswizardry.com
•@csswizardry