Scalable and Modular Architecture for CSS

Categorization

• Every style we write serves one of these purposes wheter we're aware of it or not
• Isolating code allows for easier, reuse, testing and debugging
• Categorizing reveals patterns; easier to identify when things break the pattern

Base styles

• Reset
• Normalize

Layout styles

How do you group your content

• Header
• Content
• Sidebar

Module styles

Isolate Modules from each other and prevent styles from coming in or out

• Containt content
• Are the majority of your site
• Each module is an interface that your users have to learn
• Each module is code that has to be written, delivered and maintained

Module variations

Sub-modules

State

It applies to modules.

Naming Convention

They help clarify intents

Base and Layout Names

Prefer .layout-header .layout-content .layout-footer over just .header .content .footer

• Prefer classes over ID

Module and Module variations

Modules: .btn .listview

Module variations: .btn-large .btn-small

State

.btn .btn-is-active .btn-is-disabled

Prefix states with "is-", prefix indicates likelihood of JavaScript dependency, it indicates a toggleable state. States that are specific to a module should include module name.

Theme

.theme-header .theme-border .theme-background

.text-ls .text-l .text-s

Prefixing for versioning

.next-button-is-active

Alternatives

.module-name .module-name--submodules .module-name__sub-component

moduleName

Pick a system that works for you and your team. Be consistent. Consider:

• Root node
• Sub-modules
• Sub-components

Decoupling CSS from HTML

The deeper the Depth of Applicability the harder it is to reuse the styles. Reduce the depth: Use fewer selectors and use child selectors

State-based Design

State Representation:

• Classes
• Pseudo-classes
• Attributes Selectors
• Media Queries

Avoid a state affecting more than one module at a time.

Include media queries with the modules they affect.

Preprocessors

• Variables
• Nesting
• Functions (and mixins) Handles compilation of files into final product

Protoyping

• Build and test individual components
• Allows for front-end development independent of engineering
• Create centralized repository for multiple projects
• Proto Engine can use different technology than engineering

Documentation

• Dexy
• KSS
• Hologram

Summary

Place everything in their own files

• base.css
• layout.css
• grid.css
• button.css
• carosel.css
• modal.css

Integrating JS

• Scripts are written for individual modules
• States are modified, not inline styles
• Avoid jQuery methods that add inline styles like .show() and .hide()

Converting a Project

Measure

• Perfomance
• Identify areas to refactor
• Tools: Analyze CSS, Parker, CSSCSS

Code Reviews

Give CSS the same respect as other code in your project

Don't code CSS for the page: Code it for the system

Performance

• Pull in style sheets when you need them
• Smaller rule sets make it easier on browsers
• Google Page Speed recomends a single ID or class selector

Larger Teams

• Separation of files allows multiple members of the team to work on separate files
• modules approach works well with OOP on server side (hence OOCSS)

When is SMACSS not appropiate?

• Hard to apply on user-generated content (UGC) common many content managment system.
• Benefits not felt on throwaway projects or one-offs