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.

Transcript

1. View Slide

2. Hello, Serbia!
   

   View Slide

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

   View Slide

4. #itcss
   

   View Slide

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

   View Slide

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.
   

   View Slide

7. Problems with CSS at scale
   

   View Slide

8. CSS’ fault vs. our fault
   

   View Slide

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

   View Slide

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.
    

    View Slide

11. Inheritance, the cascade, and
    source order
    

    View Slide

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

    View Slide

13. View Slide

14. CSS is one giant dependency tree.
    

    View Slide

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

    View Slide

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.
    

    View Slide

17. project.css
    

    View Slide

18. project.css
    

    View Slide

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

    View Slide

20. Poor source order coupled with

    inherited/inheriting styles can lead to a

    lot of waste and/or redundancy.
    

    View Slide

21. Specificity
    

    View Slide

22. The Specificity Wars
    

    View Slide

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.
    

    View Slide

24. The Specificity Graph
    

    View Slide

25. View Slide

26. Location in Stylesheet
    

    View Slide

27. Location in Stylesheet
    Specificity
    

    View Slide

28. Location in Stylesheet
    Specificity
    

    View Slide

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

    View Slide

30. Location in Stylesheet
    Specificity
    

    View Slide

31. How do we solve this?
    

    View Slide

32. Location in Stylesheet
    Specificity
    

    View Slide

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

    View Slide

34. Location in Stylesheet
    Specificity
    

    View Slide

35. Location in Stylesheet
    Specificity
    Generic Base Objects Components Trumps
    

    View Slide

36. These sections form the basis of ITCSS.
    

    View Slide

37. In short…
    

    View Slide

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.
    

    View Slide

39. View Slide

40. ITCSS: Inverted Triangle CSS
    

    View Slide

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

    View Slide

42. …ITCSS makes them work to

    our advantage.
    

    View Slide

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

    View Slide

44. View Slide

45. Generic
    Explicit
    

    View Slide

46. Far-reaching
    Localised
    

    View Slide

47. Low specificity
    High specificity
    

    View Slide

48. Settings
    Tools
    Generic
    Base
    Objects
    Components
    Trumps
    

    View Slide

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.
    

    View Slide

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

    View Slide

51. $color-ui: #BADA55;

    $spacing-unit: 10px;
    

    View Slide

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

    View Slide

53. @mixin font-brand() {

    font-family: "UI Font", sans-serif;

    font-weight: 400;

    }
    

    View Slide

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

    View Slide

55. * {

    -webkit-box-sizing: border-box;

    -moz-box-sizing: border-box;

    box-sizing: border-box;

    }
    

    View Slide

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

    View Slide

57. ul {

    list-style: square outside;

    }
    

    View Slide

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

    View Slide

59. .ui-list {

    margin: 0;

    padding: 0;

    list-style: none;

    }
    .ui-list__item {

    padding: $spacing-unit;

    }
    

    View Slide

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

    View Slide

61. .products-list {

    @include font-brand();

    border-top: 1px solid $color-ui;

    }
    .products-list__item {

    border-bottom: 1px solid $color-ui;

    }
    

    View Slide

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

    View Slide

63. View Slide

64. .one-half {

    width: 50% !important;

    }
    

    View Slide

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.
    

    View Slide

66. View Slide

67. View Slide

68. View Slide

69. View Slide

70. View Slide

71. View Slide

72. View Slide

73. View Slide

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

    View Slide

75. Each layer is a pass over the DOM.
    

    View Slide

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.
    

    View Slide

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

    View Slide

78. Outcomes
    

    View Slide

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!
    

    View Slide

80. Scaling ITCSS
    

    View Slide

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

    View Slide

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.
    

    View Slide

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.
    

    View Slide

84. Settings
    Tools
    Generic
    Base
    Components
    Theme
    Trumps
    

    View Slide

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

    View Slide

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

    View Slide

87. On the filesystem?
    

    View Slide

88. View Slide

89. View Slide

90. Recap
    

    View Slide

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.
    

    View Slide

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

    View Slide