Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Managing CSS Projects with ITCSS

DaFED
November 05, 2014

Managing CSS Projects with ITCSS

DaFED#27
Speaker: Harry Roberts, CSS Wizardry

Managing CSS at scale is hard; and a lot harder than it should be. ITCSS is a simple, effective, and as-yet unpublished methodology to help manage, maintain, and scale CSS projects of all sizes.
In this talk we’ll take a sneak peek at what ITCSS is and how it works to tame and control UI code as it grows.

DaFED

November 05, 2014
Tweet

More Decks by DaFED

Other Decks in Programming

Transcript

  1. 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.
  2. CSS’ fault The cascade and inheritance. Very loose. Highly dependent

    on source order. Not very expressive. Lots of gotchas. Specificity.
  3. 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.
  4. Each piece of CSS needs a knowledge of what came

    before it and what might come after it – a.k.a. dependencies.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. Base Unclassed HTML elements. H1–H6, basic links, lists, etc. Last

    layer we see type selectors (e.g. a {}, blockquote {}).
  10. Components Designed pieces of UI. Still only using classes. More

    explicitly named (e.g. .products-list {}).
  11. 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.
  12. 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.
  13. 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!
  14. Scaling ITCSS We can scale our CSS much more easily.

    But we can also scale the architecture itself!
  15. 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.
  16. 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.
  17. Booking.com run a lot of A/B tests. How do we

    isolate temporary styles? Create a Test layer (before the Trumps layer).
  18. Adding layers Add layers in the correct place. Specificity and

    explicitness of selectors should dictate this. Honour the Specificity Graph (always trending upward).
  19. 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.