Scribd
Upload
35 views

Managing CSS Projects With ITCSS - Harry Roberts

The document summarizes a presentation about ITCSS (Inverted Triangle CSS), which is a methodology for structuring CSS codebases in a scalable way. It divides CSS into layers from generic styles to more specific ones. This manages dependencies, source order, and specificity issues that can occur in large CSS codebases. The layers include settings, tools, generic, base, objects, components, and trumps. Writing CSS following this layered architecture helps reduce bugs, waste, and makes the codebase easier to maintain as it grows in size and complexity.

Uploaded by

ghb609840612
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
35 views

Managing CSS Projects With ITCSS - Harry Roberts

The document summarizes a presentation about ITCSS (Inverted Triangle CSS), which is a methodology for structuring CSS codebases in a scalable way. It divides CSS into layers from generic styles to more specific ones. This manages dependencies, source order, and specificity issues that can occur in large CSS codebases. The layers include settings, tools, generic, base, objects, components, and trumps. Writing CSS following this layered architecture helps reduce bugs, waste, and makes the codebase easier to maintain as it grows in size and complexity.

Uploaded by

ghb609840612
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 92

Hello, Serbia!

Managing CSS Projects with ITCSS


DaFED – Novi Sad, November 2014
#itcss
Harry Roberts

Consultant Front-end Architect.


Products, long-running projects, large teams, big codebases.
@csswizardry
What is ITCSS?

Inverted Triangle architecture for CSS.


A sane, scalable, managed architecture.
A school-of-thought, not a library.
A meta framework; a framework for frameworks.
Incredibly simple.
Problems with CSS at scale
CSS’ fault vs. our fault
CSS’ fault

The cascade and inheritance.


Very loose.
Highly dependent on source order.
Not very expressive.
Lots of gotchas.
Specificity.
Our fault
Lack of documentation.
Lack of structure, quality assurance.
Mixture of abilities.
Lack of knowledge (about CSS or the project itself).
Different styles, preferences, ways of working.
Not looking to see/being aware of what exists already.
Adding new styles to the end of stylesheets.
Inheritance, the cascade, and
source order
Each piece of CSS needs a knowledge of
what came before it and what might come
after it – a.k.a. dependencies.
CSS is one giant dependency tree.
We need a way to manage this dependency
at a very low level.
Ways of ordering stylesheets

Mirror the web page – old school!


Thematic chunks – typography, forms, buttons, etc.
Just stick it on the end of the stylesheet.
project.css
project.css
Undoing CSS: Writing more CSS in order to
undo other CSS.
Poor source order coupled with
inherited/inheriting styles can lead to a
lot of waste and/or redundancy.
Specificity
The Specificity Wars
It doesn’t matter how well-considered your
source order is; how well you’re utilising
the cascade; what naming conventions you
use; specificity can undo everything.
The Specificity Graph
Location in Stylesheet
Specificity

Location in Stylesheet
Specificity

Location in Stylesheet
An ID? An !important?

A nested selector?
Specificity

Location in Stylesheet
Specificity

Location in Stylesheet
How do we solve this?
Specificity

Location in Stylesheet
tl;dr: Write CSS in specificity order.
Specificity

Location in Stylesheet
Generic Base Objects Components Trumps
Specificity

Location in Stylesheet
These sections form the basis of ITCSS.
In short…
We need…

A sane environment that is accessible to lots of people.


To tame and manage source order and the cascade.
To create a place for everything to live (new and old).
To reduce waste and redundancy.
To end the Specificity Wars.
ITCSS: Inverted Triangle CSS
A lot of methodologies try and avoid or
ignore CSS’ ‘features’…
…ITCSS makes them work to
our advantage.
ITCSS is a sane, scalable, managed
architecture for CSS.
Generic

Explicit
Far-reaching

Localised
Low specificity

High specificity
Settings

Tools

Generic

Base

Objects

Components

Trumps
Default layers
Settings: Global variables, config switches.
Tools: Default mixins and functions.
Generic: Ground-zero styles (Normalize.css, resets, box-sizing).
Base: Unclassed HTML elements (type selectors).
Objects: Cosmetic-free design patterns.
Components: Designed components, chunks of UI.
Trumps: Helpers and overrides.
Settings

Globally-available settings.
Config switches.
Brand colours, etc.
$color-ui: #BADA55;
$spacing-unit: 10px;
Tools

Globally-available tools.
Public mixins.
Helper functions.
@mixin font-brand() {
font-family: "UI Font", sans-serif;
font-weight: 400;
}
Generic Ground zero styles.
Low-specificity, far-reaching.
Resets, Normalize.css, etc.
* {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}
Unclassed HTML elements.
H1–H6, basic links, lists, etc.
Base
Last layer we see type
selectors (e.g. a {},
blockquote {}).
ul {
list-style: square outside;
}
OOCSS.
Design patterns.
No cosmetics.
Begin using classes
Objects exclusively.
Agnostically named (e.g. .ui-
list {}).
.ui-list {
margin: 0;
padding: 0;
list-style: none;
}

.ui-list__item {
padding: $spacing-unit;
}
Designed pieces of UI.
Still only using classes.
More explicitly named
(e.g. .products-list {}).

Components
.products-list {
@include font-brand();
border-top: 1px solid $color-ui;
}

.products-list__item {
border-bottom: 1px solid $color-ui;
}
Overrides, helpers, utilities.
Only affect one piece of the
DOM at a time.
Usually carry !important.

Trumps
.one-half {
width: 50% !important;
}
You should notice…

Specificity slowly increases layer-by-layer.


We affect smaller and smaller bits of the DOM at a time.
Progressively adding styles; never undoing.
ITCSS…

Manages source order.


Filters explicitness.
Tames the cascade.
Sanitises inheritance.
Each layer is a pass over the DOM.
How sculptors work

Blast some rock out of a quarry.


Cut it down into a large block.
Rough it into a general shape.
Begin adding features.
Add fine details.
Each stage is more detailed and explicit
than the last one.
Outcomes
Outcomes

Everything has a place to live.


People know where to look to find types of rule.
A sane source oder.
Reduced waste/redundancy.
Increased scalability.
The Specificity Wars are over!
Scaling ITCSS
Scaling ITCSS

We can scale our CSS much more easily.


But we can also scale the architecture itself!
Scaling our CSS

No longer the end of a stylesheet to worry about.


Add things into the relevant layers (usually the last ones).
Things never get more complicated, only bigger.
Everything grows in a well-rounded manner.
The Specificity Graph keeps trending upward.
Scaling the architecture

Add or remove layers if, as, and when you need to.
Not using a preprocessor? Remove the Settings and Tools layers.
Don’t use OOCSS? Remove the Objects layer.
Need theming? Add a Theme layer.
Settings

Tools

Generic

Base

Components

Theme

Trumps
Booking.com run a lot of A/B tests.
How do we isolate temporary styles?
Create a Test layer (before the Trumps layer).
Adding layers

Add layers in the correct place.


Specificity and explicitness of selectors should dictate this.
Honour the Specificity Graph (always trending upward).
On the filesystem?
Recap
Recap

Write CSS in specificity order.


Maintain the Specificity Graph.
All rulesets should only ever add to and inherit from previous ones.
Order stylesheets from far-reaching to very localised.
Add layers as needed, but only in the right place.
Thank you – csswz.it/itcss-dafed
Harry Roberts – @csswizardry

You might also like