CSS Architecture

Beau Smith interface design & dev

Good at CSS? HTML5 Photoshop → <code> JavaScript @media queries
CSS3 Browser diﬀerences no <table>s for layout

Good at {programming lang}? extensible readable code functions decoupled from
main app modular abstract easy to change or extend scalable object-oriented DRY

<div> Lorem ipsum dolor. </div> div { color: fuschia; }

<div class="foo" > Lorem ipsum dolor. </div> .foo { color:
fuschia; }

CSS Architecture

csslint.net

The Goals of Good CSS Architecture

Predictable Reusable Maintainable Scaleable

Predictable

Reusable

Maintainable

Scaleable

Predictable Reusable Maintainable Scaleable

Common Practices =(

Modifying components based upon their parent elements .widget { width:
200px; background: yellow; border: 1px solid black; color: black; } #sidebar .widget { width: 100px; } body.homepage .widget { background: white; } ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable

Soware entities (classes, modules, functions, etc.) should be open for
extension, but closed for modiﬁcation. en.wikipedia.org/wiki/Open/closed_principle Open/Closed Principle

Overly complicated selectors #main-nav ul li ul li div {
} #content article h1:first-child { } #sidebar > div > h3 + p { } ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable

Overly generic class names <div class="widget"> <h3 class="title">...</h3> <div class="contents">
Lorem ipsum dolor sit amet, consectetur elit. <button class="action">Click Me!</button> </div> </div> .widget {} .widget .title {} .widget .contents {} .widget .action {} ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable

Making a rule do too much .widget { position: absolute;
top: 20px; left: 20px; background-color: red; font-size: 1.5em; text-transform: uppercase; } ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable

Why is this happening? ☐ Predictable ☐ Reusable ☐ Maintainable
☐ Scaleable

✦ Too much styling burden on the CSS. ✦ CSS
requiring intimate knowledge of the HTML. ✦ Too much “presentation” in the HTML. ✦ HTML elements with the sole purpose of providing CSS hooks. Why is this happening?

The Solution

✦ HTML is part of the presentation ✦ Decouple CSS
from HTML structure ✦ CSS deﬁnes style, HTML assigns style ✦ Use more classes in HTML The Solution HTML bloat?

Be intentional /* Grenade */ #main-nav ul li ul {
} /* Sniper Rifle */ .subnav { } ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable

Separate our concerns <div class="modal-primary-button"> <button class="button button-warning button-small"> Destroy
</button> </div> ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable Layout & Position Look & Feel

Namespace your classes ☐ Predictable ☐ Reusable ☐ Maintainable ☐
Scaleable <div class="widget"> <h3 class="title">...</h3> <div class="content"> Lorem ipsum dolor. </div> </div> .widget { } .widget .title { } .widget .content { } <div class="widget"> <h3 class="widget-title">...</h3> <div class="widget-content"> Lorem ipsum dolor. </div> </div> .widget { } .widget-title { } .widget-content { }

Extend components with modiﬁer classes <body id="homepage"> ... <div class="widget">
... </div> ... </body> .widget { } #homepage .widget { } <div class="widget widget-featured"> ... </div> .widget { } .widget-featured { } ☐ Predictable ☐ Reusable ☐ Maintainable ☐ Scaleable

Organize your styles into a logical structure Base Reset rules
and element defaults Layout Positioning of site-wide elements and generic layout helpers like grids Modules Reusable visual elements State Toggled states of layout or modules (via JavaScript) Theme (optional) Look and feel http://smacss.com

Use classes for styling and styling only Classes only for
styles When we see a class in HTML, you should be able to instantly understand it’s purpose. Class of unknown purpose in HTML Should we remove it? Namespace classes Perhaps use <div class="js-class-name"> to separate presentation and behavior.

Logically structured class names /* A component or sub-component? */
.button-group { } /* A component modifier for .button? */ .button-primary { } /* A component sub-component within .button? */ .button-icon { } /* Is this a component class or a layout class? */ .header { }

Logically structured class names /* Component Rules */ .component-name .component-name--modifier-name
.component-name__sub-component .component-name__sub-component--modifier-name /* Layout Rules */ .l-layout-method .grid /* State Rules */ .is-state-type /* Non-styled JavaScript Hooks */ .js-action-name

Logically structured class names /* A component */ .button-group {
} /* A component modifier (modifying .button) */ .button--primary { } /* A component sub-component (lives within .button) */ .button__icon { } /* A layout class */ .l-header { } .button-group { } .button-primary { } .button-icon { } .header { }

Tools: Preprocessors (Sass/SCSS, LESS & Stylus) ✦ Variables ✦ Operations
✦ Nesting ✦ Mixins ✦ Extend ✦ Placeholders

General CSS Rules ✦ Don’t allow IDs in your selectors.
✦ Don’t use non-semantic type selectors (e.g. DIV, SPAN) in any multi-part rule. ✦ Don’t use more than 2 combinators in a selector. ✦ Don’t allow any class names that begin with “js-”. ✦ Warn if frequently using layout and positioning for non “l-” prefixed rules. ✦ Warn if a class defined by itself is later redefined as a child of something else.

Summary ✦ CSS isn’t just visual design. ✦ Concepts like
OOP, DRY, the open/closed principle, separation of concerns, etc. still apply to CSS. ✦ Judge your organizational methods by whether they make development more eﬃcient long-term. ✦ Strive for CSS that is predictable, reusable, maintainable, and scaleable.

Credits ✦ This presentation is heavily inﬂuenced by Philip Walton’s
article on CSS Architecture. While I have been preaching many of these techniques for years, Philip laid out the arguments, techniques, and examples in a wonderful article. Thanks Philip. http://engineering.appfolio.com/2012/11/16/css-architecture

Questions? ﬁn.

@beau Thanks

CSS Architecture

CSS Architecture

More Decks by Beau Smith

Other Decks in Design

Featured

Transcript