Each solution is solving specific problems

That doesn't mean they are solving your problems

OOCSS

Didn't suit because:

• Responsive Web Design
• Rapid iteration

OOCSS (cont.)

Logical conclusion
                  

Responsive: What happens when the abstraction needs to do something different in a different scenario?

Iteration: When an element needs changing, it'll then need two touch points; template and style sheets

Note!

Atomic/ACSS.io

• I think it has a lot of merit
• Now has some great tooling around it
• Solves many of the issues I'm levelling at OOCSS
• My concern was the portability of the styling
• And continual developer education

SMACSS

Didn't suit because:

• Layout and grid styles not applicable
• Wanted to avoid HTML element type selectors
• Like OOCSS - no authoring pattern to clearly define and encapsulate overrides to a key selector
• But liked the declarative manner in which state was communicated:

.is-disabled {}

BEM

Much to take from BEM but didn't suit entirely:

• Modifiers are added to the root of a Block
• Needed some way to encapsulate all eventualities
• Disliked the actual class naming syntax
• Alternate syntaxes use -- which I associate with custom properties (and syntax highlighters can struggle with)

   
      
   
   
@User 14 minutes ago

So ??

Nothing quite solved the problems I had

"Good artists coders copy, great artists coders steal"

Dealing with states

All applications need to deal with states

A user does something:

• Taps a button
• Toggles a setting
• Rotates their device

I liked how SMACSS handled states

is-Suspended

is-Live

is-Busy

Old Skool Button

But now we have ARIA

States re-done as ARIA

• aria-disabled="true" (used instead of is-Suspended)
• aria-live="polite" (used instead of is-Live)
• aria-busy="true" (used instead of is-Busy)

Class handles aesthetics, aria-* handles state

Authoring states in style sheets

.co-Button {
   background-color: $color-button-passive; 
   &[aria-live="polite"] {
      background-color: $color-button-selected;
   }
}

Caveats

Two touch-points for JavaScript: classes and attributes (rather than just one)

button.setAttribute("aria-disabled", "true");

The Ten Commandments of Sane Style Sheets

Blessed are those that follow these rules for they shall inherit sane style sheets

Amen

ECSS uses PostCSS to enable a Sass-like syntax and facilitate additional tooling^*

1

Thou shalt have a single source of truth for all key selectors

1

.key-Selector { 
   width: 100%;
   @media (min-width: $M) { 
      width: 50%;
   }
   .an-Override_Selector & {
      color: $color-grey-33;
   }
}

A key selector should only be found as the root of a rule once in the entire project: a single source of truth

2

Thou shalt not nest

3

Thou shalt not use id selectors

An even specificity across rules allows for more manageable style sheets

4

Thou shalt not write vendor prefixes in the authoring style sheets

Autoprefixer means you can author styles as intended

5

Thou shalt use variables for sizing, colours and z-index

$size-full: 11px; 
$size-half: 5.5px;
$size-quarter: 2.75px;
$size-double: 22px;
$size-treble: 33px;
$size-quadruple: 44px;

Variables serve large projects well by normalising sizing and colours

Better to think of variables as const

6

Thou shalt always write rules mobile first (avoid max-width)

6

.med-Video {
   position: relative;
   background-color: $color-black;
   font-size: $text13;
   line-height: $text15;
   /* At medium sizes we want to bump the text up */ 
   @media (min-width: $M) {
      font-size: $text15;
      line-height: $text18; 
   }
   /* Text and line height changes again at larger viewports */
   @media (min-width: $L) { 
      font-size: $text18; 
      line-height: 1;
   }
}

7

Use mixins sparingly (and avoid @extend)

7

• You shouldn't need more than 10 mixins in a project
• Text truncation, scroll panels and font-stacks that are media query dependent are good candidates. Everything else is probably a needless abstraction
• @extends offer minor KB savings when gzipped but add additional complexity

8

Thou shalt comment all magic numbers and browser hacks

Errant px values that aren't pre-defined in the variables should serve as a red flag

Any non-standard values or browser specific hacks should be commented

9

Thou shalt not place data URIs in the authoring style sheets

9

Don't do this:

.rr-Outfit {
   min-height: $size-quadruple;
   background-image: url(data:image/gif;base64,iVBORw0KGgoAAAANSUh
   EUgAAABAAAAAQCAMAAAAoLQ9TAAAAA3NCSVQICAjb4UgAAAAw1BMVEX///8AAAC
   EhIQAAABYWFgAAAAAAAAAAAB6enomJiYAAAAiIiJ4eHgAAABiYmJgYGAAAACJiY
   kAAAC0tLR/f3/IyMjHx8e/v7+vr6+fn5+ZmZmUlJSBgYFmZmYiIiIQEBAAAAD//
   //w8PDv7+/i4uLh4eHf39/W1tbS0tLR0dHMzMzHx8fFxcXCwsK/v7+4uLi0tLSv
   r6+rq6ulpaWfn5+ZmZmQkJCPj498fHxwcHBgYGBAQEAwMDAgICAfHx8QEBAAAAA
   phWZmAAAAQXRSTlMAESIiMzNEVWZmZneIiKqqu8zM3d3u7u7u7u7u7u7u7u7///
   //////////////////////////////////////wP/q/8AAAAJcEhZcwAACxIAAA
   sSAdLdfvwAAAAVdEVYdENyZWF0aW9uIFRpbWUAMjEvNS8xMpVX8IQAAAAcdEVYd
   FNvZnR3YXJlAEFkb2JlIEZpcmV3b3JrcyBDUzVxteM2AAAAw0lEQVQYlU2P6VLC
   UAyFD1KvWFQ2F1ChnLLW2oIs1ZZC8/5PRW4rM+RH5uSbLCeARt2YO2Pq+I+aafU
   AAAAAElFTkSuQmCC);
}

9

Instead do this:

.rr-Outfit {
   min-height: $size-quadruple;
   background-image: inline("/path/to/relevant-image.png");
}

Lean on tooling where it can provide a better authoring experience

10

Thou shalt not write complicated CSS when simple CSS will work just as well

Only move as far as necessary from standard CSS; makes static analysis easier

Tooling

Ask anyone who works with me and they'll tell you I'm a tooling addict

PostCSS facilitates incredible tools for CSS

An ECSS approach benefits from a number of tools in the PostCSS eco-system

Game changers for CSS codebases

• Autoprefixer
• Linting

Autoprefixer

Autoprefixer remains the gold standard for automatically adding any needed vendor prefixes

Use it!

Linting

Stylelint is a Node based linting tool for the static analysis of style sheets

Example Stylelint Configuration

var stylelintConfig = { 
   "rules": {      
      "color-hex-case": "lower",
      "color-hex-length": "short",
      "color-named": "never",
      "color-no-invalid-hex": true,
      "font-family-name-quotes": "always-where-required",
      "font-weight-notation": "numeric",
      "function-comma-newline-before": "never-multi-line",
      "function-comma-newline-after": "never-multi-line",
      "function-comma-space-after": "always",
      "function-comma-space-before": "never",
      "function-linear-gradient-no-nonstandard-direction": true,
      "function-max-empty-lines": 0
   }
};

I keep my full config here

Configure it to fail your build

Over 150 rules!

Code QAs just got a whole lot easier!

Bonus: Aggressive minification

cssnano is a modular CSS minifier. Use the features you want, switch off the ones you don't. Easy bolt-on to your PostCSS build

• Convert lengths (16px => 1pt)
• Rebase z-index (z-index: 1000 => z-index: 10)
• Duplicate rule removal

Finished?

Devised a system, written extensive docs, briefed the team, added tooling

4 months later

.P2 .bb-ParticipantBettingBanner .ip-Participant_OppName {
      padding-left: 11px;
      margin-right: .5em;
      @media (min-width: 640px) {
      & .ip-Participant_OppName {
      display: inline-block;
   }
}
}

With many devs, conventions are difficult to enforce

Good will and documentation only get you so far

If there's a way to screw things up, people will find it

You need to continually refine your process

You need to be the Fun Police!

More rules!

Additional rules

• Prevent key selectors from being compound (e.g. .ip-Selector.ip-Selector2 {})
• Ensure key selectors are singular (e.g. .ip-Thing not .a-Parent .ip-Thing {})
• Ensure only overrides and media queries can be nested (prevents nests that don't use a parent (&) selector)
• Ensure that key selectors match ECSS naming conventions
• Limit specificity and nesting levels

Yes, more!

• prevent descending specificity
• Disallow imperceptibly different colour values
• Disallow type selectors
• Ensure disabling Stylelint has a comment

The aim is for all style sheets to appear as if written by a single author

Implementation considerations

This is not particular to ECSS. But if you're about to start on a similar journey, I hope some of what follows may be useful

Prototype

Test and re-test the approach. Don't grab something 'off the shelf' and stick it into production

Document the failures

Ensure you document what didn't work

"Those who cannot remember the past are condemned to repeat it"

Adapt

Be ready to adapt. We started with utility styles (e.g. u-w50) but found they caused more problems than they solved

There are many ways to solve these problems. Evaluate approaches against your own requirements

Don't be a sheep!