Component-based CSS

6fe15a7e096eb9517a201a249e57aa80?s=47 Mirjam
March 10, 2018

Component-based CSS

Slides from my session about "Component-based CSS" at the DeveloperCamp in Würzburg.

6fe15a7e096eb9517a201a249e57aa80?s=128

Mirjam

March 10, 2018
Tweet

Transcript

  1. Component-based CSS Developer Camp 2018

  2. DAE?

  3. Component-based CSS pros • reusable • more maintainable • more

    comprehensible in the markup • easier to refactor • plays nicely with the component-based web
  4. Nice! But...

  5. .component-one { position: relative; font-family: "Fancy Font"; font-weight: 500; font-size:

    20px; color: #ff99ff; width: 100%; height: 880px; margin-bottom: 20px; padding: 10px 15px; background-color: #000033; }
  6. .component-two { position: relative; font-family: "Fancy Font"; font-weight: 700; font-size:

    15px; color: #ff99ff; width: 100%; height: 880px; margin-top: 20px; padding: 10px 15px; background-color: #000033; }
  7. .component-three { font-family: "Fancy Font"; font-weight: 500; font-size: 20px; color:

    #ff99ff; height: 880px; margin-top: 20px; background-color: #000033; border-top: 1px solid #ff99ff; &:hover { background-color: #ff99ff; color: #000033; } }
  8. What about repetition?

  9. CSS component !== Web Component • Not every CSS component

    mirrors a component in the markup. • Seperation of concern. (Ok. Kinda.)
  10. My current approach for seperation Basic component general styles like:

    fontstyles, colors, variables Utility component repeating styles that can be used universally Conterpart component counterpart to our web component
  11. Characteristics Basic component Are like a CI Styleguide. They'll tell

    you how the brand looks and behaves like. Utility component Helps you with all the things you would write over and over again. They'll support you with a consistent style on a small level. Conterpart component They determine the rules how a specific web component has to look like. The component will work in every place of the markup.
  12. Rules

  13. Naming consistent and clear • mirror web component name &

    use them for scoping • use speaking class names • don't generate unexpected results (sideeffects)
  14. Naming approach - components .ComponentOne { color: pink; .ComponentOne-logo {

    height: 120px; } //alternativ &-logo { height: 120px; } } // the scoping adds a bit of saftey
  15. Naming approach - utility & basic .text-lg { font-size: $font-base

    * 1.5; } .d-flex { display-flex; } .background-warning { background-color: $warning-color; } // ( ᐛ )و
  16. Nope .background-red { background-color: $warning-color; // $warning-color = orange; font-weight:

    bold; } // <(ҹ^´)>
  17. Markup Use composition to define appearance. <div class="ComponentOne m-3"> <div

    class="text-lg text-center background-warning"> <p>ALERT</p> </div> </div>>
  18. Nest components, not styles Components can be nested in other

    components, but never nest CSS components to overwrite styles. <div class="SearchResult d-flex"> stuff <div class="ButtonComponent"> some stuff </div> </div> <!-- (*^-^) -->
  19. .ButtonComponent { font-size: 10px; padding-top: 5px; padding-bottom: 5px; } .SearchResult

    { .ButtonComponent { font-size: 10px; padding-top: 10px; padding-bottom: 10px; } } // ( ಠ ಠ )
  20. Never add styles based on location .ComponentTwo { div {

    .d-flex { background-color: red; } } } // ҵ(`O´)҈
  21. Create independent web components Counterpart components should only contain styles

    that define their unique apparance, they're independent from their environment. You should be able to put them anywhere in the markup without changing their style.
  22. #LifeProTips

  23. My #LPT so far (Part 1) • don't write CSS

    on the side, think about a useful architecture for your project • plan your "CI styleguide" carefully • use and adapt the styleguide • commit to and write down naming rules • refactor early and often - CSS grows rampart if you don't look at it for, like, 5 minutes
  24. My #LPT so far (Part 2) • use your basic

    and utility components generously • if you write similar styles the third time, think about creating utility components • unify rules and styles when possible - there's seldom need for margin: 13px and margin: 14px in the same view • if you add the third variation of a style to a dynamic web component, think about creating a new one
  25. And that's it! Feel free to contact me with questions.

    My approach is still work in progress so I'm very happy about feedback when you give it a try. Twitter: @mirjam_diala Github: programmiri