Tweet
Tweet

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

CSS Architecture (a guide to managing scale and complexity)

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

CSS Architecture you say…

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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…

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Principles • Separation of concerns • Naming convention • Proper namespacing

Slide 11

Slide 11 text

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)

Slide 12

Slide 12 text

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/

Slide 13

Slide 13 text

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…

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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/

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 32

Slide 32 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 35

Slide 35 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 41

Slide 41 text

Settings Utilities Tools Reset Components Objects Generic Hacks

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Thoughts & Questions?

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

Thank you!