t

We needto talk about CSS

We do our best to keep it together

But try as we might

chaos takes us in the end

Day by day our CSS grows

It grows disorganized

Our files are long and contain unrelated styles

It isn't clear how and when to break CSS up into separate files

It growsfragile

Making changes feels unsafe

WE

WENEED

WENEEDHELP

Is the answer out there?

OOCSS SMACSS BEM MCSS

We need guiding principals for organizing our CSS

What do we call it? Where do we put it?

We need robust stylesheets we can change gracefully

How can I style this page without breaking other pages?

Any worthwhile methodology would help with our problems

We need a methodology but which one?

Let’s give it a shot

SMACSS Scalable, Modular

Architecture for CSS

1. Consider the intent of a style

Base Layout Module

Module subclassModule component

State Theme

Express your intent by following a naming scheme

2.

BaseSet the default style for an element type

a { color: red;}a:hover { color: purple; text-decoration: none;}

This is the only place you should see tag names in your stylesheets.

LayoutDefine a component that structures a page

.l-sidebar { float: left; width: 320px;}

Prefix layout components with ’l-’.

ModuleDefine a type of thing

.activity { border-bottom: 1px solid #eee;}

Most CSS we write will define modules

Module subclassDefine a variation of a module

.activity--metric-share { background-color: white;}

Prefix subclassed modules with ‘module-name--‘.

Module componentDefine a component that exists only within a specific module.

.activity__icon { float: right; color: #d5d5d5;}

Prefix a component with ‘module-name__’.

StateDefine a state of a layout or module

.is-collapsed { height: 0; margin-bottom: 0;} .activity-is-read { background-color:#eee;}

Prefix global states with ‘is-‘.Prefix module-specific states with ‘module-name-is-‘.

Module subclasses and states are both variations on modules. !

How do we tell them apart? !

A subclass is applied at markup time. A state is applied and removed at runtime.

*

ThemeDefine the appearance of a module

// in _thing.less .thing { display: block;}// in fun_theme.less .thing { border: 4px dashed magenta;}

We won’t use this intent

ThemeDefine the appearance of a moduleWe won’t use this intent

Define modules without decorative properties in a module file.

Decorate all modules in a single theme file.

Include a single theme file on a page.

Where do we put this stuff?

Base /_base.less !

Layout /_layout.less

Global states /_states.less

Modules /modules/_module_name.less

Subclassed modules, components, and module-specific states go with their parent module.

I propose a couple more patterns

JS selectors

<div class=“js-toggle-agreers"></div> !$('.js-toggle-agreers') .click(this.toggleAgreers);

When you need to select an element in a view give that element a classname beginning with ‘.js’.Apply no style to that class.

We want to know which classes are safe to change, and which will cause behavior to break

Region selectors

<div class=“js-comments-region"></div> !layout: { comments: ‘.js-comments-region'}

When you need to select a class to become a view region append that class with ‘-region’.Apply no style to that class.

Property ordering.module { // Box properties display: block; width: 100%; margin: 0 0 18px 0; // Background & border background-color: perrywinkle; border: 1px solid: lavendar; // Typography color: #666; line-height: 20px; text-decoration: none; // Other -webkit-transition: all .4s ease-in-out;}

Group related properties

That was cathartic