Decoupling the Front-end with Modular CSS

Decoupling the Front-end with
Modular CSS
Julie Cameron
@jewlofthelotus
#OSCON 2015
bit.ly/decoupling-css

DERP.
@jewlofthelotus | #OSCON

articulate.com@jewlofthelotus | #OSCON

girldevelopit.com@jewlofthelotus | #OSCON

OOCSS

Got CSS?

#cascade {
div.is {
span.delicate {
position: absolute !important;
}
}
}

“It’s almost a challenge to ﬁnd a development
team that’s working on a codebase that’s more
than a couple of years old where the CSS isn’t
the most frightening and hated part of that
system.”
Andy Hume - CSS for Grownups

TOP DOWN CSS
=
REPETITION & BLOAT

SELECTOR MISUSE
=
SPECIFICITY HELL

BLOAT
+
BAD SELECTORS
=
BAD PERFORMANCE

!IMPORTANT
=
THE DEVIL

NONE OF THIS IS
SCALABLE OR
MAINTAINABLE.
A hot mess is what it is…

TOP
DOWN
OVERLY
SPECIFIC
CSS
HTML@jewlofthelotus | #OSCON

WE’VE BEEN
COUPLING OUR
HTML & CSS

WE’VE BEEN
COUPLING OUR
HTML & CSS
And sometimes our CSS & JavaScript.

WE’VE BEEN
COUPLING OUR
HTML & CSS
And sometimes our CSS & JavaScript. …and Feature Specs, too.

Coupled CSS Selectors

STOP USING
CSS SELECTORS
FOR NON-CSS
Data Attributes. FTW.

Functionality Selectors

START USING
MODULAR CSS

MODULAR

PREDICTABLE

MAINTAINABLE

SCALABLE

ORGANIZED

Modular Solutions
• OOCSS
• BEM
• SMACSS
• Atomic Design
• CSS for Grownups
• CCSS
• DRY CSS
• and many more…

Object Oriented Cascading Stylesheets
OOCSS
https://github.com/stubbornella/oocss/wiki

A scalable, maintainable,
semantic, and predictable
approach to writing CSS.

OOCSS was created by Nicole Sullivan
while working for Facebook.
She created a reusable CSS module
called the “media object” to save
hundreds of lines of code.
stubbornella.org

The Media Object
“a content block containing a ﬁxed-size
media element (e.g. image or video) along
with other variable-size content (e.g. text)”
https://github.com/stubbornella/oocss/wiki
AKA a Facebook status.

A Media Object
Media to the left and some
variable length content to
the right.
img.png

The Foundation of Modular CSS
OBJECTS

Objects are the
abstraction of repetition.

Object Makeup
1. HTML - one or more nodes of the DOM
https://github.com/stubbornella/oocss/wiki/FAQ

Object Makeup
2. CSS that styles those nodes

Object Makeup
2. CSS that styles those nodes
3. JavaScript functionality tied to those nodes

Modules with Variations
.btn

.btn
.btn—primary .btn-small
CSS
.btn:hover

.btn
.btn.is—disabled .btn.is-active
CSS
JS
.btn—primary .btn-small
CSS
.btn:hover

Module Components
Object aka module / component / block .btn, .media

Module Components
Child Objects .media__img, .media__body
Relationships

Module Components
Modiﬁers .media—-inline, .media__img—-right
CSS Design Variations
Relationships

Module Components
Modiﬁers .media—-inline, .media__img—-right
CSS Design Variations
States .media—-collapsed, .media.is-active
CSS / JS Design Adjustments
Relationships

BEST
PRACTICES

SINGLE
RESPONSIBILITY
Do one thing well and one thing only.

.CLASSES
.CLASSES
.CLASSES
Take that, speciﬁcity!

NAMING
CONVENTIONS
Just breathe. Everything is going to be okay.

PICK A SYSTEM
BE CONSISTENT

Naming Formats
.modulename
.moduleName
.module-name
.module_name
.bem——style
.bem_ _style

Naming Patterns
How do you identify children? States? Modifiers?
.objectChild
.object-child
.object_child
.object_ _child
.myObject—childObj
.object.is—active
.objectModifier
.object-modifier
.object_modifier
.object——modifier
.myObj-modClass
.object.active

BEM
.block__element——modiﬁer
http://bem.info

.block .media

.block .media
.block__element .media_ _img

.block .media
.block——modiﬁer .media——inline

.block .media
.block——modiﬁer .media——inline
.block__element——modiﬁer .media_ _img——right

SEMANTIC
VS
PRESENTATIONAL
NAMING
Uh oh…

Presentational Naming
Describes how the object looks.
.grid_ _col——9
.btn——small
.border——all
.color——red
.ﬂoat——left
.border——thick

Semantic Naming
Describes what the object is.
.bookmark
.article
.callToAction
.error
.article_ _title
.article——ﬂagged

Fewer Semantic Classes
DRY HTML
VS
DRY CSSMany Presentational Classes

NO ONE KNOWS
WHAT THEY’RE
DOING.

2 Principles
of OOCSS

Separation of
STRUCTURE
from
SKIN
1ST PRINCIPLE

Structure Vs. Skin

Structure Vs. Skin
Deﬁne repeating “invisible” patterns
as reusable structures.
What makes a button look like a button?

Structure Vs. Skin
Deﬁne repeating “invisible” patterns
as reusable structures.
Deﬁne repeating visual patterns
as reusable skins.
What makes these buttons look different?

Structure
Repeating “invisible” patterns.

Skin
Repeating visible patterns.
What makes these buttons look different?

Structure + Skin

Structure + Skin
.btn .btn—primary
.btn—small
.btn—block
.btn—inverse

Separation of
CONTAINER
from
CONTENT
2ND PRINCIPLE

Container Vs. Content
Objects should look the same
no matter where you put them.

Location Dependent Styles

Better?

Separation Of
Container & Content
What is the container?

Separation Of
Container & Content
What is the content?

Separation Of
Container & Content
Abstract reusable styles into a new object.

With OOCSS, we’re encouraged to give
more forethought to what is common
among different elements, then separate
those common features into modules, or
objects, that can be reused anywhere.
Louis Lazaris — Smashing Magazine

OOCSS
Structure vs. Skin
Container vs. Content

CLASSITIS

HTML <3 CSS

HTML <3 CSSCSS
STYLE

The Semantics Debate
• Do classes actually have “semantic” value?

• To whom are classes semantic to?

• To whom are classes semantic to?
• Should we stick with one way or the other?

Presentational
Arguments
• Classes have NO meaning to the browser.

Presentational
Arguments
• Classes ARE semantic to developers.

Presentational
Arguments
• Classes ARE semantic to developers.
• Content describes itself, classes don’t need to.

Semantic
DRY HTML
VS
DRY CSSPresentational

SMACSSScalable & Modular Architecture with CSS
http://smacss.com
Jonathan Snook

CATEGORIZATION

• Base
• Layout
• Module
• State
• Theme
SMACSS Categories

CSS Resets
+
Default Styles
What things should generally look like.
SMACSS Base Objects

Containers
+
Grids
Hold the modules together.
SMACSS Layout Objects
#IDs for single use “major” components
.classes for reusable “minor” components

Reusable Parts
+  
Subclasses
(Modiﬁers)
The good stuff.
SMACSS Modules

Tacked on to layout
& module objects
Indicate a JavaScript dependency.
SMACSS State Objects
!important is allowed and even recommended!

Tacked on to layout
& module objects
Indicate a JavaScript dependency.
SMACSS State Objects
!important is allowed and even recommended!
Module-speciﬁc
State objects
Include module name & reside with it.
pseudo & @media query states included.

Themes can
apply to all other
object types
In the case that your site has multiple
holistic themes.
SMACSS Themes

ATOMIC
DESIGN
http://bradfrost.com/blog/post/atomic-web-design
Brad Frost

ASSEMBLING

Atomic Design
atoms molecules organisms templates pages

Atomic Design
atoms molecules organisms templates pages
+@jewlofthelotus | #OSCON

The basic building
blocks of matter.
Single element. Global styles.
Atoms

Groups of atoms
bonded together.
Simple combinations built for reuse.
Molecules

Groups of molecules
joined together.
Complex, distinct sections of an interface.
Organisms

http://patternlab.io
A collection of tools to help you create
atomic design systems.
Pattern Lab

WHAT
NOW?

ORGANIZE
OPTIMIZE
REPEAT@jewlofthelotus | #OSCON

ITERATING ON
ABSTRACTION

FINDING THE RIGHT
GRANULARITY

ESTABLISH
CONVENTIONS

DOCUMENT
EVERYTHING

ARCHITECT A
STYLEGUIDE

UTILIZE A CSS
PREPROCESSOR

STOP USING
CSS SELECTORS
FOR NON-CSS

http://github.com/davidtheclark/scalable-css-reading-list
http://bit.ly/dc-scrl
LEARN
MORE

Questions?
Decoupling the Front-end with
Modular CSS
Julie Cameron
@jewlofthelotus
#OSCON 2015
bit.ly/decoupling-css

Decoupling the Front-end with Modular CSS

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (6)

Similaire à Decoupling the Front-end with Modular CSS

Similaire à Decoupling the Front-end with Modular CSS (20)

Dernier

Dernier (20)

Decoupling the Front-end with Modular CSS