CSS Architecture

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