Tweet
Tweet

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Hello, Serbia!

Slide 3

Slide 3 text

Managing CSS Projects with ITCSS DaFED – Novi Sad, November 2014

Slide 4

Slide 4 text

#itcss

Slide 5

Slide 5 text

Harry Roberts Consultant Front-end Architect. Products, long-running projects, large teams, big codebases. @csswizardry

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

Problems with CSS at scale

Slide 8

Slide 8 text

CSS’ fault vs. our fault

Slide 9

Slide 9 text

CSS’ fault The cascade and inheritance. Very loose. Highly dependent on source order. Not very expressive. Lots of gotchas. Specificity.

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

Inheritance, the cascade, and source order

Slide 12

Slide 12 text

Each piece of CSS needs a knowledge of what came before it and what might come after it – a.k.a. dependencies.

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

CSS is one giant dependency tree.

Slide 15

Slide 15 text

We need a way to manage this dependency at a very low level.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

project.css

Slide 18

Slide 18 text

project.css

Slide 19

Slide 19 text

Undoing CSS: Writing more CSS in order to undo other CSS.

Slide 20

Slide 20 text

Poor source order coupled with
 inherited/inheriting styles can lead to a
 lot of waste and/or redundancy.

Slide 21

Slide 21 text

Specificity

Slide 22

Slide 22 text

The Specificity Wars

Slide 23

Slide 23 text

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.

Slide 24

Slide 24 text

The Specificity Graph

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

Location in Stylesheet

Slide 27

Slide 27 text

Location in Stylesheet Specificity

Slide 28

Slide 28 text

Location in Stylesheet Specificity

Slide 29

Slide 29 text

Location in Stylesheet Specificity A nested selector? An ID? An !important?

Slide 30

Slide 30 text

Location in Stylesheet Specificity

Slide 31

Slide 31 text

How do we solve this?

Slide 32

Slide 32 text

Location in Stylesheet Specificity

Slide 33

Slide 33 text

tl;dr: Write CSS in specificity order.

Slide 34

Slide 34 text

Location in Stylesheet Specificity

Slide 35

Slide 35 text

Location in Stylesheet Specificity Generic Base Objects Components Trumps

Slide 36

Slide 36 text

These sections form the basis of ITCSS.

Slide 37

Slide 37 text

In short…

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

ITCSS: Inverted Triangle CSS

Slide 41

Slide 41 text

A lot of methodologies try and avoid or ignore CSS’ ‘features’…

Slide 42

Slide 42 text

…ITCSS makes them work to
 our advantage.

Slide 43

Slide 43 text

ITCSS is a sane, scalable, managed architecture for CSS.

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

Generic Explicit

Slide 46

Slide 46 text

Far-reaching Localised

Slide 47

Slide 47 text

Low specificity High specificity

Slide 48

Slide 48 text

Settings Tools Generic Base Objects Components Trumps

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

Settings Globally-available settings. Config switches. Brand colours, etc.

Slide 51

Slide 51 text

$color-ui: #BADA55;
 $spacing-unit: 10px;

Slide 52

Slide 52 text

Tools Globally-available tools. Public mixins. Helper functions.

Slide 53

Slide 53 text

@mixin font-brand() {
 font-family: "UI Font", sans-serif;
 font-weight: 400;
 }

Slide 54

Slide 54 text

Generic Ground zero styles. Low-specificity, far-reaching. Resets, Normalize.css, etc.

Slide 55

Slide 55 text

* {
 -webkit-box-sizing: border-box;
 -moz-box-sizing: border-box;
 box-sizing: border-box;
 }

Slide 56

Slide 56 text

Base Unclassed HTML elements. H1–H6, basic links, lists, etc. Last layer we see type selectors (e.g. a {}, blockquote {}).

Slide 57

Slide 57 text

ul {
 list-style: square outside;
 }

Slide 58

Slide 58 text

Objects OOCSS. Design patterns. No cosmetics. Begin using classes exclusively. Agnostically named (e.g. .ui- list {}).

Slide 59

Slide 59 text

.ui-list {
 margin: 0;
 padding: 0;
 list-style: none;
 } .ui-list__item {
 padding: $spacing-unit;
 }

Slide 60

Slide 60 text

Components Designed pieces of UI. Still only using classes. More explicitly named (e.g. .products-list {}).

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

Trumps Overrides, helpers, utilities. Only affect one piece of the DOM at a time. Usually carry !important.

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

.one-half {
 width: 50% !important;
 }

Slide 65

Slide 65 text

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.

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

No content

Slide 74

Slide 74 text

ITCSS… Manages source order. Filters explicitness. Tames the cascade. Sanitises inheritance.

Slide 75

Slide 75 text

Each layer is a pass over the DOM.

Slide 76

Slide 76 text

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.

Slide 77

Slide 77 text

Each stage is more detailed and explicit than the last one.

Slide 78

Slide 78 text

Outcomes

Slide 79

Slide 79 text

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!

Slide 80

Slide 80 text

Scaling ITCSS

Slide 81

Slide 81 text

Scaling ITCSS We can scale our CSS much more easily. But we can also scale the architecture itself!

Slide 82

Slide 82 text

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.

Slide 83

Slide 83 text

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.

Slide 84

Slide 84 text

Settings Tools Generic Base Components Theme Trumps

Slide 85

Slide 85 text

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

Slide 86

Slide 86 text

Adding layers Add layers in the correct place. Specificity and explicitness of selectors should dictate this. Honour the Specificity Graph (always trending upward).

Slide 87

Slide 87 text

On the filesystem?

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

No content

Slide 90

Slide 90 text

Recap

Slide 91

Slide 91 text

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.

Slide 92

Slide 92 text

Thank you – csswz.it/itcss-dafed Harry Roberts – @csswizardry