Component-based CSS Developer Camp 2018 

DAE? 

Component-based CSS pros • reusable • more maintainable • more comprehensible in the markup • easier to refactor • plays nicely with the component-based web 

Nice! But... 

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

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

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

What about repetition? 

CSS component !== Web Component • Not every CSS component mirrors a component in the markup. • Seperation of concern. (Ok. Kinda.) 

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 

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. 

Rules 

Naming consistent and clear • mirror web component name & use them for scoping • use speaking class names • don't generate unexpected results (sideeffects) 

Naming approach - components .ComponentOne { color: pink; .ComponentOne-logo { height: 120px; } //alternativ &-logo { height: 120px; } } // the scoping adds a bit of saftey 

Naming approach - utility & basic .text-lg { font-size: $font-base * 1.5; } .d-flex { display-flex; } .background-warning { background-color: $warning-color; } // ( ᐛ )و 

Nope .background-red { background-color: $warning-color; // $warning-color = orange; font-weight: bold; } // <(ҹ^´)> 

Markup Use composition to define appearance. > 

Nest components, not styles Components can be nested in other components, but never nest CSS components to overwrite styles. 

.ButtonComponent { font-size: 10px; padding-top: 5px; padding-bottom: 5px; } .SearchResult { .ButtonComponent { font-size: 10px; padding-top: 10px; padding-bottom: 10px; } } // ( ಠ ಠ ) 

Never add styles based on location .ComponentTwo { div { .d-flex { background-color: red; } } } // ҵ(`O´)҈ 

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. 

#LifeProTips 

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 

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 

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