Managing CSS Projects with ITCSS

C1d9295b73069d0182d61895048713d8?s=47 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.

C1d9295b73069d0182d61895048713d8?s=128

DaFED

November 05, 2014
Tweet

Transcript

  1. None
  2. Hello, Serbia!

  3. Managing CSS Projects with ITCSS DaFED – Novi Sad, November

    2014
  4. #itcss

  5. Harry Roberts Consultant Front-end Architect. Products, long-running projects, large teams,

    big codebases. @csswizardry
  6. 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.
  7. Problems with CSS at scale

  8. CSS’ fault vs. our fault

  9. CSS’ fault The cascade and inheritance. Very loose. Highly dependent

    on source order. Not very expressive. Lots of gotchas. Specificity.
  10. 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.
  11. Inheritance, the cascade, and source order

  12. Each piece of CSS needs a knowledge of what came

    before it and what might come after it – a.k.a. dependencies.
  13. None
  14. CSS is one giant dependency tree.

  15. We need a way to manage this dependency at a

    very low level.
  16. 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.
  17. project.css

  18. project.css

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

    CSS.
  20. Poor source order coupled with
 inherited/inheriting styles can lead to

    a
 lot of waste and/or redundancy.
  21. Specificity

  22. The Specificity Wars

  23. 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.
  24. The Specificity Graph

  25. None
  26. Location in Stylesheet

  27. Location in Stylesheet Specificity

  28. Location in Stylesheet Specificity

  29. Location in Stylesheet Specificity A nested selector? An ID? An

    !important?
  30. Location in Stylesheet Specificity

  31. How do we solve this?

  32. Location in Stylesheet Specificity

  33. tl;dr: Write CSS in specificity order.

  34. Location in Stylesheet Specificity

  35. Location in Stylesheet Specificity Generic Base Objects Components Trumps

  36. These sections form the basis of ITCSS.

  37. In short…

  38. 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.
  39. None
  40. ITCSS: Inverted Triangle CSS

  41. A lot of methodologies try and avoid or ignore CSS’

    ‘features’…
  42. …ITCSS makes them work to
 our advantage.

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

  44. None
  45. Generic Explicit

  46. Far-reaching Localised

  47. Low specificity High specificity

  48. Settings Tools Generic Base Objects Components Trumps

  49. 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.
  50. Settings Globally-available settings. Config switches. Brand colours, etc.

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

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

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

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

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

  56. Base Unclassed HTML elements. H1–H6, basic links, lists, etc. Last

    layer we see type selectors (e.g. a {}, blockquote {}).
  57. ul {
 list-style: square outside;
 }

  58. Objects OOCSS. Design patterns. No cosmetics. Begin using classes exclusively.

    Agnostically named (e.g. .ui- list {}).
  59. .ui-list {
 margin: 0;
 padding: 0;
 list-style: none;
 } .ui-list__item

    {
 padding: $spacing-unit;
 }
  60. Components Designed pieces of UI. Still only using classes. More

    explicitly named (e.g. .products-list {}).
  61. .products-list {
 @include font-brand();
 border-top: 1px solid $color-ui;
 } .products-list__item

    {
 border-bottom: 1px solid $color-ui;
 }
  62. Trumps Overrides, helpers, utilities. Only affect one piece of the

    DOM at a time. Usually carry !important.
  63. None
  64. .one-half {
 width: 50% !important;
 }

  65. 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.
  66. None
  67. None
  68. None
  69. None
  70. None
  71. None
  72. None
  73. None
  74. ITCSS… Manages source order. Filters explicitness. Tames the cascade. Sanitises

    inheritance.
  75. Each layer is a pass over the DOM.

  76. 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.
  77. Each stage is more detailed and explicit than the last

    one.
  78. Outcomes

  79. 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!
  80. Scaling ITCSS

  81. Scaling ITCSS We can scale our CSS much more easily.

    But we can also scale the architecture itself!
  82. 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.
  83. 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.
  84. Settings Tools Generic Base Components Theme Trumps

  85. Booking.com run a lot of A/B tests. How do we

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

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

  88. None
  89. None
  90. Recap

  91. 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.
  92. Thank you – csswz.it/itcss-dafed Harry Roberts – @csswizardry