3. “
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/
4. Issues
If you’ve ever worked on a
medium to large website, you
have probably come across a
range of issues with CSS.
17. “
“We have been doing it all
wrong.... Our best practices are
killing us”
”
Nicole Sullivan
18. “
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/
55. 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.
61. 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.
66. Boxes?
You may have noticed that there
were also a series of smaller
boxes, each with an image to the
left or right.
67.
68. Core purpose
1. contain content
2. feature object to left or right
3. content beside feature object
4. margin below
69. 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
70. 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
71. 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.
72. There are a range of possible
class we could use here.
.box { }
.box-feature { }
.box-feature-alt { }
.box-body { }
.box-heading { }
.box-content { }
73. Width
Do not give the box a width -
allow it to spread to fit the width
of any parent container.
74. Contain floats
This box module must contain
(and therefore wrap around)
either a left or right floating
object. We can solve this by
triggering the block formatting
context on the parent.
76. Location Agnostic
The box must work when placed
anywhere within the layout. The
box must be “location agnostic”.
aside .box { }
.box { }
77. 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.
78. BFC again
We can solve this by triggering
the block formatting context on
the “box-body” class.
79. box-body
This is a heading
Lorem ipsum dolor sit amet consect etuer
adipi scing elit sed diam nonummy nibh
euismod tinunt ut laoreet dolore magna
aliquam erat volut.
88. Semantic classes
For years, we have been taught
to keep our markup clean and
only use “semantic” class names.
89. 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?
90. “
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/
91. “
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/
92. “
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
93. Move forward
In order to move forward,
especially on large scale sites, we
cannot keep using old practices.
94. Solution?
OOCSS offers front end
developers an alternative - light
weight, modular CSS that can be
re-used repeatedly across sites.
97. “
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
98. In 2011, Jonathan
Snook introduced a
new way of looking at
CSS architecture.
He called this
Scalable and Modular
Architecture for CSS
(SMACSS)
113. Modifiers
Possibly use different naming
conventions for modifiers,
sub-modules and states.
.example-widget { }
.example-widget--modifier { }
.example-widget__sub-module { }
.example-widget--is-somestate { }
115. “
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/
116. Decouple
So how do we “decouple” our
HTML and CSS.
1. using additional class names
2. using child selectors
117. 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”.
118. This is a heading heading
Lorem ipsum dolor sit amet consect etuer
adipi scing elit sed diam nonummy nibh
euismod tinunt ut laoreet dolore magna
aliquam erat volut.
119. Style the h2?
We could style this heading using
something like this:
.box { }
.box h2 { }
129. “
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/
130. Keep ‘em simple
The base module should be
defined as simply as possible.
This means that they are highly
flexible.
131. 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;
}
132. 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.
134. “
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/
135. Don’t undo
Leading on from the first rule, you
should avoid writing rules to undo
a previous module.
136. For example, what if you wanted
almost all of your headings to
have a border-bottom?
h2 {
! font-size: 1.5em
! margin-bottom: 1em;
! padding-bottom: 1em;
! border-bottom: 1px solid red;
}
137. But in some cases you might
want a heading without a
border-bottom.
138. You could write a new rule like
this:
.no-border {
! padding-bottom: 0;
! border-bottom: none;
}
139. This is not ideal. It is much better
to write sub-modules that add
styles, rather than write sub-
modules to undo styles.
140. So, a better way might be to
write two rules like this:
143. Don’t modify
Base modules can be extended
using sub-modules. However, the
base module itself should never
be modified.
144. This is based on the object
oriented programming “open/
close principle”.
145. “
Software entities (classes,
modules, functions, etc.) should
be open for extension, but closed
for modification.
”
http://en.wikipedia.org/wiki/Open/closed_principle
146. If a based module needs to be
modified to suit a specific case, it
is probably better to create a
new module.
148. 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.
149. 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”.
153. 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
154. “
"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
155. /**
* 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
*/
157. Single line?
In the early days of CSS, a lot of
developers preferred single line
CSS rules as they could easily
see the selectors.
158. 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.
159. 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/
167. 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/