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. 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