Upgrade to Pro — share decks privately, control downloads, hide ads and more …

CSS Architecture

r31gN_
July 25, 2016

CSS Architecture

r31gN_

July 25, 2016
Tweet

More Decks by r31gN_

Other Decks in Technology

Transcript

  1. Who’s that sexy guy? • Name: Vlad Zelinschi • Nickname:

    Reign • Occupation: Lead Frontend Engineer at Appsbroker • Real occupation: talks gibberish on Twitter (@vladzelinschi), writes sloppy code on Github (vladzelinschi), writes stupid articles on his blog, dances in Oxford??? • Misc: lover of the web, coffee addict
  2. What? • A standard • A meta framework • A

    collection of principles laid out in code designed to help the developer • A guide for managing scale and complexity
  3. Why the need? • CSS is old and permissive •

    CSS is declarative (there is no control flow to give clues in regards to the state or shape of the project) • CSS is disconnected from HTML, though they’re part of the same team • Specificity is a pain in the arse
  4. Why the need? • CSS operates in a global namespace

    • Source order is critical for CSS • CSS is based on inheritance and cascading styles • Writing CSS is easy. Writing good, scalable, maintainable, transparent and self-documenting CSS is not…
  5. Principles • Low specificity • Highly composable and decoupled •

    Single Responsibility Principle (SRP) • Open-Closed Principle
  6. Low specificity • Specificity is the main cause of headaches

    in CSS • Keep it low at all costs • It can be hacked if you need to, but that’s not the idea • Use classes over IDs, keep them simple, don’t over-qualify or nest heavily (preprocessors)
  7. Highly composable • The days of long, monolithic CSS stylesheets

    are gone • We must think in terms of components and composable pieces • We get flexibility in return • eg: Pattern Lab - http://patternlab.io/
  8. Highly decoupled • Avoid reliance on other parts of the

    system • Code that doesn’t know about other code is a good thing • We get reduced dependency • Ignorance is bliss…
  9. SRP • Keep things focused (structure, layout, presentation, etc.) and

    small • Do one thing, and one thing well • Use composition to build up your components
  10. Open-Closed Principle • Add via extension not modification • Keep

    change and extension self-contained and separated • Allows safe modifications later on
  11. Separation of concerns • Don’t overstep the mark • Let

    each piece of code deal with its own functionality and be self-managed • Keep things specialized - don’t mix presentation with layout on same class, etc.
  12. – Phil Karlton “There are only two hard things in

    Computer Science: cache invalidation and naming things.” Naming convention Eminem
  13. Naming things • Hard to get right the first time

    • Aim for reusability • We need a structure, an established pattern • Enter the BEM-like syntax - https://en.bem.info/
  14. Namespacing • Proper namespacing will offer us even more information

    about a piece of code • Small effort - prefixing our classes • Enforces consistency, transparency and keeps things separated
  15. Combining everything • My take on CSS architecture (it’s not

    the best nor the only one…) • Built to be a starter for every project • It is not opinionated in regards to presentation (it is the developer’s choice) • Work in progress… • Community effort, so please contribute :)
  16. reign-css (great name) • Layered approach • Built with specificity

    graph in mind • Composability (class level) • Separation of concerns (dedicated layers)
  17. reign-css • Decouples every piece of reasoning code and makes

    it live in its own space • Components will be your most “expensive” folder • Heavy use of SoC and SRP which are the base for scalability and maintainability
  18. Challenges • Focus on the right things • Add body

    without losing intent and scope - it is not presentation opinionated (identify critical objects and components to be added) • Keep it synced with latest standards • Proper documentation and a team style guide
  19. Advice… Always code as if the person who ends up

    maintaining your code is a violent psychopath who knows where you live.