$30 off During Our Annual Pro Sale. View Details »

CSS Architecture

r31gN_
July 25, 2016

CSS Architecture

r31gN_

July 25, 2016
Tweet

More Decks by r31gN_

Other Decks in Technology

Transcript

  1. View Slide

  2. CSS Architecture
    (a guide to managing scale and complexity)

    View Slide

  3. View Slide

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

    View Slide

  5. CSS Architecture
    you say…

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  9. Principles
    • Low specificity
    • Highly composable and decoupled
    • Single Responsibility Principle (SRP)
    • Open-Closed Principle

    View Slide

  10. Principles
    • Separation of concerns
    • Naming convention
    • Proper namespacing

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  14. SRP
    • Keep things focused (structure, layout,
    presentation, etc.) and small
    • Do one thing, and one thing well
    • Use composition to build up your components

    View Slide

  15. View Slide

  16. Open-Closed Principle
    • Add via extension not modification
    • Keep change and extension self-contained and
    separated
    • Allows safe modifications later on

    View Slide

  17. View Slide

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

    View Slide

  19. – Phil Karlton
    “There are only two hard things in Computer
    Science: cache invalidation and naming
    things.”
    Naming convention
    Eminem

    View Slide

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

    View Slide

  21. View Slide

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

    View Slide

  23. View Slide

  24. 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 :)

    View Slide

  25. https://github.com/
    vladzelinschi/reign-css

    View Slide

  26. reign-css (great name)
    • Layered approach
    • Built with specificity graph in mind
    • Composability (class level)
    • Separation of concerns (dedicated layers)

    View Slide

  27. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks
    (Specificity increase)
    (Base)
    (Top)

    View Slide

  28. View Slide

  29. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  30. View Slide

  31. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  32. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  33. View Slide

  34. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  35. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  36. View Slide

  37. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  38. View Slide

  39. View Slide

  40. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  41. Settings
    Utilities
    Tools
    Reset
    Components
    Objects
    Generic
    Hacks

    View Slide

  42. View Slide

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

    View Slide

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

    View Slide

  45. Advice…
    Always code as if the person who ends up
    maintaining your code is a violent
    psychopath who knows where you live.

    View Slide

  46. Thoughts
    &
    Questions?

    View Slide

  47. Nicolae Guta
    “Keep on smiling.
    You are the most beautiful when you do.”
    – Reign

    View Slide

  48. Thank you!

    View Slide