CSS Architecture: Writing Maintainable CSS

CSS Architecture
Writing maintainable CSS
Alexei Skachykhin – Software Engineer
iTechArt, 2015

“Writing CSS is easy. Scaling CSS
and keeping it maintainable is not.”
Ben Frain

Guess what makes
it hard to maintain

“I don’t understand the cultural fascination with
failure being the source of great lessons to be
learned. You might know what won’t work, but you
still don’t know what will work.”
Basecamp
Excerpt from “Rework”

What’s missing?
CSS that works to spec isn’t enough, it
should be considered as a baseline

We need a plan to keep CSS styles organized.
We call such plan an architecture

Growing Complexity
7,046
Rules
10K
Selectors
16,8K
Declarations
90
Unique Colors

Growing Complexity
3,938
Rules
5,164
Selectors
9,826
Declarations
46
Unique Colors

Repetitive Design
“We’re not designing pages,
we’re designing systems of components.”
Stephen Hay

Technical Difficulties
 Source order affects application order
 Specificity is hard to deal with
 CSS operate in global scope
 Permissive by its nature

1. Evolving Design
2. Growing Complexity
3. Repetitive Design
4. Technical Difficulties

It is time to follow architecture
and cleanup our CSS

Building Blocks
UI consists of components, where
component is any distinguishable element
of the design

Building Blocks
Writing CSS is not about making HTML
elements look like provided PSD, but
translating system of components into Web
compatible format

.contact-item {
float: left;
font-size: 28px;
.contact-item .contact-item__info {
margin-top: 4px;
margin-left: 20px;
padding-left: 31px;
}
.contact-item .contact-item__title {
margin: 0;
font-family: 'Lato', sans-serif;
font-size: 16px;
font-weight: bold;
}
.contact-item .contact-item__text {
margin: 1px 0 14px;
font-size: 14px;
}
}
.subscribe {
.clearfix();
.field-group {
.clearfix();
}
.sign-up-button {
.secondary-button;
.variant-action;
display: block;
border: none;
}
ul {
margin: 5px;
li {
display: inline-block;
}
}
}
COMPONENT STYLED HTML

Design and markup are inseparable.
Designers and Front-End Engineers must speak
ubiquitous language to succeed.

CSS Architecture
Components &
Other Styles
Dependency
Management
Physical Structure &
Deployment

Goals of Architecture
Predictable Reusable
Maintainable Scalable

Goals of Architecture
Predictable Reusable
Maintainable Scalable
Minimal
Complexity

“Everyone else in the W3C CSS Working Group, the
group which defines the future of CSS, fits the profile
of a developer much more than that of a designer.”
Lea Verou

Existing Solutions
 BEM
 OOCSS
 SMACSS
 Atomic CSS
 MCSS
 ITCSS

#1 DOM Independency
CSS component styles must not rely on
particular DOM structure

Example
div.social-links {
> div a {
color: blue;
}
}
 Visual styles are tightly coupled with
markup which makes them hard to
evolve
 Reusability of component is limited
 Ambiguity that leads to growth of
specificity

Rule
Avoid any signs of DOM elements in CSS
code including references to HTML tags, ID
(#) and (>) child selectors

Rule
CSS selectors must convey semantics of the
component and it’s integral parts. Class
selector conveys a lot, element selector
almost none

Example
.social-links {
.social-links__item {
color: blue;
}
}

#2 Location Independency
CSS component styles must not rely on
component’s location on a page

Example
.button {
color: white;
}
.sidebar {
.button {
color: orange;
}
}
 Component is no longer self contained
entity and its visual appearance is not
predictable at dev time
 Leads to growth of specificity

Rule
Component styles must not be written in
reliance on their location on a page, instead
provide location independent variations that
can be used anywhere

“Instead of saying - The buttons need to be smaller
when they’re in the header, we need to be saying - We
have a smaller variant of our buttons, and it’s these that
we use in the header.”
Harry Roberts

.button {
color: white;
/* Other declarations */
&.button--variant-action {
color: orange;
}
}
Example

#3 Limited Complexity
CSS components can be complex and have
integral parts, but no more than having 1 (2)
layers of descendant styles

Example
.filter {
.filter__header {
.filter__header__icon {
/* Declarations */
}
}
.filter__list {
.filter__list__link {
/* Declarations */
}
}
}
 Component is too complex which
makes it hard to maintain
 Following that style may lead to
unnecessary dependencies between
integral parts

Rule
If CSS styles have no dependency they must
not form parent-child relationship

Rule
Complex components must be split into
simpler components

.filter {
.filter__header {}
.filter__icon {
/* Declarations */
}
.filter__list {}
.filter__link {
/* Declarations */
}
}
Example

#4 Enforced Naming
All aspects of component definition must be named in a
way to communicate their relationship clearly and
protect from incorrect use

.infobox /* Block */ {
.infobox__body /* Element */ {}
.infobox__footer {}
.infobox__title {}
&.infobox--size-full /* Modifier */ {}
}
Example

#5 Explicit States
Dynamic behavior must be implemented with state
classes that JavaScript toggles. No direct style
manipulation is allowed with JavaScript.

open: function () {
elements.root.show();
elements.trigger.css('color', 'blue');
},
close: function () {
elements.root.hide();
elements.trigger.css('color', 'white');
}
Example
 Visual appearance of component is
now split across JavaScript and CSS
which makes is hard to maintain
 There is no simple undo operation
for setting style properties in
JavaScript so previous state has to
be maintained somewhere or inline
styles manipulated directly

open: function () {
elements.root.addClass('state-open');
elements.trigger.addClass('state-active');
},
close: function () {
elements.root.removeClass('state-open');
elements.trigger.removeClass('state-active');
}
Example

Rule
Global states must not collide with local
states to avoid overrides in CSS

.state-hidden {
display: none;
}
.infobox {
&.state-hidden {
visibility: hidden;
}
}
Example
 Component is no longer self contained
which causes inclusion of override
declarations
 In some cases may lead to a need to
have !importants

.global-state-hidden {
display: none;
}
.infobox {
&.state-hidden {
visibility: hidden;
}
}
Example

#6 JavaScript Hooks
Never use component classes to select elements with
JavaScript. Introduce specialized classes just for the
sake of selecting elements.

Example
var elements = {
mailing_list: internal.$e,
form: internal.$e.find('.social-widget__query'),
submit_button: internal.$e.find('.button'),
submit_button_text: internal.$e.find('span'),
validation_message: internal.$e.find('.social-widget__validation-message')
};
 Hard to modify component styles due to dependencies in
JavaScript. Makes whole component fragile

Example
<div class="social-widget social-widget--inversed js-mailing-list">
<div class="social-widget__title">Stay in the loop</div>
<form class="social-widget__query js-mailing-list-form">
<input class="js-mailing-list-email" type="text" name="email" placeholder="Email address">
<label class="button">
<span class="js-mailing-list-submit-button-text">Submit</span>
<input class="js-mailing-list-submit-button" type="submit">
</label>
</form>
<div class="js-mailing-list-validation-message social-widget__validation-message state-hidden">
Email is not in correct format!
</div>
</div>

#7 Local Media Queries
Responsiveness of a page must be based on
responsiveness of each component thus Media Query
must be local to a component

.blog-entry {
.blog-entry-body {
/* Declarations */
}
}
.infobox {}
@media @phone {
.blog-entry {
.blog-entry-body {
/* Declarations */
}
}
.infobox {}
}
Example
 Code duplication makes components
hard to maintain
 Components are not self-contained
which makes the outcome less
predictable at dev time

.blog-entry {
.blog-entry-body {
margin-right: @gutter / 2;
margin-bottom: @gutter / 2;
margin-left: @gutter / 2;
@media @phone {
margin-left: @gutter_phone / 2;
margin-right: @gutter_phone / 2;
}
}
}
Example

.infobox /* Component */ {
.infobox__body /* Integral Part */ {}
&.infobox--size-full /* Variant */ {}
&.state-active /* State */ {}
@media @phone /* Responsive */ {}
}
.js-infobox /* JavaScript Hook */
Anatomy of Component

#8 Layout vs Visual
Layout aspects should be moved to dedicated
components or integral parts

.infobox {
/* Layout */
float: left;
padding-left: @half-col-gutter;
padding-right: @half-col-gutter;
width: 33.33%;
/* Visual */
background-color: green;
padding: 10px; /* Collision */
}
Example
 Limits reusability
 Usually require additional html
elements just as styling hooks

Grid based layout is an emerging trend in Web and
Graphics design

.grid-row {
.clearfix();
.grid-row__column {
float: left;
padding-left: @half-col-gutter;
padding-right: @half-col-gutter;
width: 33.33%;
}
}
.infobox {
background-color: green;
padding: 10px;
}
Example

#9 Container vs Content
Container components must define layout and size
constraints, content components – visual look
(occasionally size constraints too)

Rule
Don’t make any assumptions about content
on container level

Rule
Develop CSS components to be container
agnostic

Types of Styles
Base
(Normalize, Reset)
Utilities
(clearfix, valign)
Typography
(Fonts, Headings, …)
Constants
(Colors, Sizes, …)

Physical Structure &
Deployment

Physical Structure
Single file for
all of the styles
Single file with
comments
One file per
type of styles
One file per
component

Fallacies
 Use id selectors for performance reasons
 Too many classes is a bad thing, style based on tags
 Nest CSS selectors to follow DOM hierarchy
 Put all styles into single file all the time because it is
easier to maintain
 Introduce lots of utility classes to have greater flexibility
when styling things

Thank you!
Forward your questions to
alexei.skachykhin@live.com

CSS Architecture: Writing Maintainable CSS

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to CSS Architecture: Writing Maintainable CSS (20)

More from Alexei Skachykhin (6)

Recently uploaded (20)

CSS Architecture: Writing Maintainable CSS

Editor's Notes