CSS - OOCSS, SMACSS and more

what’s wro
ng with

CSS

“
CSS is simple... It’s simple to
understand. But CSS is not
simple to use or maintain.

”
http://chriseppstein.github.com/blog/2009/09/20/why-stylesheet-abstraction-matters/

Issues
If you’ve ever worked on a
medium to large website, you
have probably come across a
range of issues with CSS.

Repetition
Lots of ﬂoats, font-size
references, heading levels
repeated...

Unmanageable
It may have started out well, but it
has become a mess?

Weight war
You need to add some CSS - so
you have to start adding to
selectors in order to win.

Coupling
Your CSS is speciﬁcally tied to
HTML or location...

CSS sucks!
Developers have been telling us
for years that “CSS sucks”. We
all know it’s time for our CSS
practices to evolve.

New stuff!
Luckily, there are a wide range of
exciting new developments to
explore.

Biases aside...
Before we start... put aside any
biases. At least until after the
presentation, when you can rip
into me :)

In 2009, Nicole
Sullivan introduced a
new way of looking
at CSS. She deﬁned
this as Object
Oriented CSS
(OOCSS).

Statistics
After optimising Facebook’s CSS,
she discovered some amazing
statistics... about how we reapply
CSS properties throughout our
style sheets.

Facebook:
Facebook blue 261
Unique colors 548
colors 6,498

Salesforce:
padding 3,668
h1-h6 511

“
“We have been doing it all
wrong.... Our best practices are
killing us”

”
Nicole Sullivan

“
The purpose of OOCSS is to
encourage code reuse and,
ultimately, faster and more
efficient stylesheets that are
easier to add to and maintain.

”
http://coding.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/

Looking for patterns -
rows

Abstraction
One of the key aims of OOCSS
is to abstract as many
components of the layout as
possible.

Example
Can you see any repeating visual
patterns?

Rows
The ﬁrst layout pattern could be
the rows.

Past practice
In the past, people may have
styled these rows using a series
of IDs.

#header

#main

#news

#footer

OOCSS aims
1. use a single class so that it can
be reused as needed
2. abstract the module down to
core purposes

Core purposes
These rows have two purposes:
1. clear each row
2. trigger the block formatting
context.

.row

.row

.row

.row

Re-use
Then we can write one simple,
but very powerful class that can
be reused anywhere in the layout.

.row {
! clear: left; Clears each row

! overflow: hidden; Triggers block formatting

! zoom: 1; Triggers haslayout in IE5-7

! _overflow: visible; IE6 underscore hack

}

Different rows
Did you notice that two of the
rows were different? They have
different background colours and
additional padding above and
below.

New names?
We could now add some classes
based on the purpose of these
rows - such as “news” and
“footer”.

.news {
! padding: 1em 0;
! background-color: blue;!
}

.footer {
! padding: 1em 0;
! background-color: pink;!
}

Abstract
However, it would be better to
abstract these names further so
that they are more ﬂexible.

.row {
! clear: left;
! overflow: hidden;
! zoom: 1;
! _overflow: visible;
}

.row-alt1 {
! padding: 1em 0;
}

.row-alt2 {
! padding: 1em 0;
}

Further
If you wanted, these could be
abstracted even further into
padding and backgrounds as
separate concepts.

.row-padding {
! padding: 1em 0;
}

.bg-color1 {
}

.bg-color2 {
}

Up to you
It depends on the site and
circumstances as to how far you
think you need to abstract these
concepts.

Primary module
The “row” class is our primary
module. The additional classes
are “modiﬁers” as they modify
the primary class.

Modifiers
Modiﬁers should not rewrite any
aspect of the primary module,
they only modify or add to the
primary module.

Types of class
Primary module Sub-module Modiﬁer
.row-alt1 .row-alt1

columns

Columns
The second layout pattern could
be the columns. The wide layout
looks like it has four columns.

Column 1 Column 2 Column 3 Column 4

Patterns
Some of the rows spread across
all columns. Others spread
across two or one column.

Column 1 Column 2 Column 3 Column 4

4 columns

2 columns 2 columns

2 columns 2 columns

1 columns 1 columns 1 columns 1 columns

Framework 1
To be safe, we should assume we
need containers for 4, 3, 2 and 1
column widths. We can convert
these column options into a
simple grid framework.

Wide layout Class names
4 column box .w-4col

Narrow
The same is true of the narrow
layout, except this time it has
only two overall columns.

2 columns

1 columns 1 columns

1 columns 1 columns

1 columns 1 columns

Framework 2
We could also create a second,
different grid for narrow screen.
This would allow us to control
whether columns sat beside each
other or below at a narrower
screen size.

Narrow layout Class names
2 column box .n-2col
1 column box .n-2col

Control!
With these two simple grids, we
can control complicated layouts -
both wide and narrow.

boxes

Boxes?
You may have noticed that there
were also a series of smaller
boxes, each with an image to the
left or right.

Core purpose
1. contain content
2. feature object to left or right
3. content beside feature object
4. margin below

Adaptable box
We need to create an adaptable box:
- could be placed anywhere
- any width or height
- any feature content
- feature content could be left/right
- any content inside the body

Target
We need to be able to target
- the overall box
- the object (left or right)
- the body content within the box
- a possible heading (h1-h6)
- possibly even the contents itself

box
box body
This is a heading heading
box
box feature
Lorem ipsum dolor sit amet consect etuer
adipi scing elit sed diam nonummy nibh
box content
euismod tinunt ut laoreet dolore magna
aliquam erat volut.

There are a range of possible
class we could use here.

.box { }
.box-feature { }
.box-feature-alt { }
.box-body { }
.box-heading { }
.box-content { }

Width
Do not give the box a width -
allow it to spread to ﬁt the width
of any parent container.

Contain floats
This box module must contain
(and therefore wrap around)
either a left or right ﬂoating
object. We can solve this by
triggering the block formatting
context on the parent.

.box {

! zoom: 1;
! margin-bottom: 1em;
}

Location Agnostic
The box must work when placed
anywhere within the layout. The
box must be “location agnostic”.

aside .box { }
.box { }

Sit beside
The box may contain objects that
have varying widths. We need our
content box (“box-body”) to sit
beside these objects, regardless
of their widths.

BFC again
We can solve this by triggering
the block formatting context on
the “box-body” class.

box-body
This is a heading
aliquam erat volut.

.box-body {

! zoom: 1;
}

Powerful box
We have just made a very
powerful box. Nicole Sullivan
refers to this box as the “media”
element.

.box,.box-body {
! overflow: hidden;
! zoom: 1;
}

.box { margin: 0 0 10px; }

.box-feature {
! float: left;
! margin: 0 10px 0 0;
}

.box-feature-alt {
! float: right;
! margin: 0 0 0 10px;
}

Primary module
In this case, the “box” class is
our primary module. There are no
modiﬁers, but there are a range of
sub-modules.

Sub-modules
Sub-modules are other classes
associated with the primary
module. They do not alter or add
directly to the primary module.

Types of class
.row-alt1 .row-alt1
.box .box-feature
.box-body

Semantic classes
For years, we have been taught
to keep our markup clean and
only use “semantic” class names.

Break the rules?
OOCSS seems to break both of
these rules - and in a big way.
But have we been thinking about
“semantic” class names in the
wrong way?

“
HTML class names offer no
semantic value to search engines
or screen readers, aside from
microformats.

”
http://www.brettjankord.com/2013/02/09/thoughts-on-semantic-html-class-names-and-maintainability/

“
Rather than concerning
ourselves with creating semantic
class names, I think we should be
thinking about creating sensible
class names. Sensible class
names offer semantics, but they

”
also offer flexibility/reusability.
http://www.brettjankord.com/2013/02/09/thoughts-on-semantic-html-class-names-and-maintainability/

“
If your class is called “blue” and
you want to change it to red, you
have far bigger problems than
class names to deal with!

”
https://speakerdeck.com/andyhume/css-for-grown-ups-maturing-best-practises

Move forward
In order to move forward,
especially on large scale sites, we
cannot keep using old practices.

Solution?
OOCSS offers front end
developers an alternative - light
weight, modular CSS that can be
re-used repeatedly across sites.

“
SMACSS is more style guide than
rigid framework - an attempt to
document a consistent approach
to site development when using
CSS.

”
http://alistapart.com/article/frameworksfordesigners

In 2011, Jonathan
Snook introduced a
new way of looking at
CSS architecture.
He called this
Scalable and Modular
Architecture for CSS
(SMACSS)

Categories
Base rules
Layout rules
Module (and sub-module) rules
State rules
Theme rules

Base
Base rules are the defaults. They
are almost exclusively single
element selectors.

Layout
Layout rules divide the page into
sections. Layouts hold one or
more modules together.

Modules
Modules are the reusable,
modular parts of our design. They
are the callouts, the sidebar
sections, the product lists and so
on.

SMACSS allows for
primary modules, modiﬁers
and sub-modules, though they
are labelled slightly differently.

Sub-component Sub-module
.row-alt1 .row-alt1
.box .box-feature
.box-body

States
State rules are ways to describe
how our modules or layouts will
look when in a particular state. Is
it hidden or expanded?

Themes
Theme rules describe how the
layout or modules might look.

Avoid IDs
Use classes rather than IDs for
styling purposes. Classes are
more ﬂexible. Using classes can
reduce speciﬁcity issues.

Meaningful
Class names should be
meaningful for other authors, so
that other developers can
understand their purpose.

Pattern
Class names should follow
understandable patterns.

Prefixes
Use “pseudo-namespaces” as
prefixes - so that modules,
modifiers and sub-modules can
be identified.

Modifiers
Possibly use different naming
conventions for modiﬁers,
sub-modules and states.

.example-widget { }
.example-widget--modifier { }
.example-widget__sub-module { }
.example-widget--is-somestate { }

“
I’ve noticed that designers
traditionally write CSS that is
deeply tied to the HTML that it is
designed to style. How do we
begin to decouple the two for
more flexible development with

”
less refactoring?
http://coding.smashingmagazine.com/2012/04/20/decoupling-html-from-css/

Decouple
So how do we “decouple” our
HTML and CSS.
1. using additional class names
2. using child selectors

Example
To see this in action, let’s look at
the “box” example from earlier.
What if we wanted to style the
heading inside the “box-body”.

This is a heading heading

aliquam erat volut.

Style the h2?
We could style this heading using
something like this:

.box { }
.box h2 { }

<div class="box">
! <img class="box-feature"
! src="dummy-140.png" alt="">
! <div class="box-body">
! ! <h2>Heading</h2>
! ! </p>Lorem ipsum dolor</p>
! </div>
</div>

Problem?
The problem is that the CSS is
“coupled” with the HTML. What
happens if there is an <h3>
element inside the box?

One solution would be to set all
heading levels.

.box { }
.box h1 { }
.box h2 { }
.box h3 { }
.box h4 { }
.box h5 { }
.box h6 { }

Use a class
However, the safest way to
“uncouple” the CSS and HTML
would be to use a simple class.

<div class="box">
! <img class="box-feature"
! src="dummy-140.png" alt="">
! <div class="box-body">
! ! <h2 class="box-heading">
! ! ! Heading</h2>
! ! </p>Lorem ipsum dolor</p>
! </div>
</div>

More flexible
Now our HTML and CSS are more
ﬂexible. It doesn’t matter what
heading level is used.

.box { }
.box-heading { }

Guidelines
The following “module” guidelines
apply regardless of whether you
are coming from OOCSS or
SMACSS.

“
By making your base objects this
simple your choices become
boolean; you use the object or
you don’t. The object is either
entirely suitable as a basis, or
entirely _un_suitable.

”
http://csswizardry.com/2012/06/the-open-closed-principle-applied-to-css/

Keep ‘em simple
The base module should be
deﬁned as simply as possible.
This means that they are highly
ﬂexible.

Let’s use an example of our “row”
class. What if we added some
padding to this rule?

.row {
! clear: left;
! overflow: hidden;
! padding: 20px 0;
}

But what if we want a row that
doesn’t have padding? The
problem is that this rule is now
very specifically defined. It is
therefore not as flexible.

“
Any CSS that unsets styles (apart
from in a reset) should start
ringing alarm bells... Rulesets
should only ever inherit and add
to previous ones, never undo.

”
http://csswizardry.com/2012/11/code-smells-in-css/

Don’t undo
Leading on from the ﬁrst rule, you
should avoid writing rules to undo
a previous module.

For example, what if you wanted
almost all of your headings to
have a border-bottom?

h2 {
! font-size: 1.5em
! padding-bottom: 1em;
! border-bottom: 1px solid red;
}

But in some cases you might
want a heading without a
border-bottom.

You could write a new rule like
this:

.no-border {
! padding-bottom: 0;
! border-bottom: none;
}

This is not ideal. It is much better
to write sub-modules that add
styles, rather than write sub-
modules to undo styles.

So, a better way might be to
write two rules like this:

/* default style */
h2 {
! font-size: 1.5em
}

/* only when border needed */
.headline {
! padding-bottom: 1em;
! border-bottom: 1px solid red;
}

Rule 3:
extend but don’t
modify

Don’t modify
Base modules can be extended
using sub-modules. However, the
base module itself should never
be modiﬁed.

This is based on the object
oriented programming “open/
close principle”.

“
Software entities (classes,
modules, functions, etc.) should
be open for extension, but closed
for modification.

”
http://en.wikipedia.org/wiki/Open/closed_principle

If a based module needs to be
modiﬁed to suit a speciﬁc case, it
is probably better to create a
new module.

Rule 4:
think before adding
new modules

Don’t rush
It is always tempting to add a
module based on your need at
the time... as well as based on
the needs of the system.

This often happens after the initial
planning and build has been
done. It’s easy to be tempted by
“I’ll just drop this new class in
at the bottom of my CSS”.

However, adding poorly
structured new modules, without
rigorous abstraction, will lead to
bloated, hard-to-manage CSS.

DocBlock
There is a growing trend to use
the DocBlock as an overall
comment convention. In fact, a
movement around this type of
commenting began over 6 years
ago with the CSSdoc group

“
"A DocBlock is an extended C++-
style PHP comment that begins
with "/**" and has an "*" at the
beginning of every line.
DocBlocks precede the element
they are documenting...

”
http://en.wikipedia.org/wiki/PHPDoc

/**
* Short desc
*
* Long description first sentence starts
* and continues on this line for a while
* finally concluding here at the end of
* this paragraph
*
* The blank line above denotes a paragraph
*/

Single line?
In the early days of CSS, a lot of
developers preferred single line
CSS rules as they could easily
see the selectors.

Multi-line
Today, with the complexity of
individual rules, most developers
seem to prefer either the
multi-line format, or multi-line
with indenting format.

CSS Tricks rule formatting poll

Multi-line Format with Indenting 44%
Multi-line Format 28%
Single-line Format 11%
Single-line Format with Indenting/Tabbing 5%
Mostly Single-line Format 5%
Single-line Format with Tabbing 4%
Other 3%

*CSS-tricks poll: http://css-tricks.com/different-ways-to-format-css/

.navigation_rss_icon {
! position: absolute;
! left: 940px;
! bottom: 0px;
}

#navigation_rss {
! position: absolute;
! left: 720px;
! font-family: Verdana, Arial, Helvetica, sans-serif;
! text-transform: uppercase;
! color: #897567;
! line-height: 2.5em;
}

#navigation_rss li {
! display: inline;
}

#navigation_rss li a:link, #navigation_rss li a:visited {
! color: #fffffe;
! text-decoration: none;

.navigation_rss_icon {
position: absolute;
left: 940px;
bottom: 0px;
}

#navigation_rss {
position: absolute;
left: 720px;
font-family: Verdana, Arial, Helvetica, sans-serif;
text-transform: uppercase;
color: #897567;
line-height: 2.5em;
}

#navigation_rss li {
display: inline;
}

#navigation_rss li a:link, #navigation_rss li a:visited {
color: #fffffe;
text-decoration: none;

Alphabet?
Similarly, many developers used
to prefer to sort their declarations
alphabetically.

Group
Today, most people prefer to
group their declarations by type.

CSS Tricks declaration formatting poll

Grouped by type 45% 45%
Random - 39% 39%
Alphabet - 14% 14%
By line - 2% 2%

*CSS-tricks poll: http://css-tricks.com/different-ways-to-format-css/

.selector {
/* Positioning */
position: absolute;
z-index: 10;
top: 0;
right: 0;

/* Display & Box Model */
display: inline-block;
overflow: hidden;
box-sizing: border-box;
width: 100px;
height: 100px;
padding: 10px;
border: 10px solid #333;
margin: 10px;

/* Color */
background: #000;
color: #fff

/* Text */

Of course, many tools and pre-
processors take care of this for
you. If your tools do not have this
capability, take a look at CSS
Comb
http://csscomb.com/

Russ Weakley
Max Design

Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
Linkedin: linkedin.com/in/russweakley

CSS - OOCSS, SMACSS and more

More Related Content

What's hot

Viewers also liked

Similar to CSS - OOCSS, SMACSS and more

More from Russ Weakley

Recently uploaded

CSS - OOCSS, SMACSS and more