in Development ~ read.

Architecting Good CSS

I was really impressed by Nicolas Gallagher's talk about SuitCSS. Though I've been a SASS and Stylus fan for a while, I appreciate the way he thinks about his CSS. As I get more clever with my preprocessing css development, I've realized that I'm forgetting to approach css with some core architecture principals.

Just because SASS has map, does it make sense to nest ever subcomponent?

Nicolas mentions something I currently relate to, which is blaming the client when you aren't able to make code perfect.

'I would have done it differently but they changed the spec.'

This is just part of development. It's our role as devs to think of how our code can last through change, or for other developers.

Ideas I like:

  • Think to make everything a component
  • State is scoped to a component: encapsulation over DRY
  • Use restraint on design, ie - breakpoint limitation
  • Use decendent pattern
.Tweet {...} /* Component */
.Tweet-text {...} /* decendent */
  • Avoid Inheritence
.Avatar {...} /* Component */
.Avatar--large {...} /* modifier */

The benefit of SuitCSS is creating a component-based approach to decouple archetecture. 'Components are encapsulated but are able to interoperate via interfaces/events.'

The goals of good css:

  • Modularity
  • Cohesion
  • Composition and configuration
  • Loose coupling
  • Soft encapsulation
  • Documentation
  • Components should be singularly focused and contain a full design of all parts.
  • Components do not need to know anything about where it is or outer context. This includes HTML, CSS, JavaScript, and associated assets.
  • The functionality and presentation defined by a component must be semantically related.
  • Components do not have direct influence over each other.
Composable and configurable
  • Composability is concerned with the inter-relationships of components. Composable systems have components that can be assembled in various combinations, as required.
  • Configuration is done via interfaces that are provided and used by components.
Loose coupling
  • Components shouldn't impact parent elements. Relying on interfaces and events for inter-component communication results in a loose coupling.
  • Don't attempt to reuse too much code across components. It can increase their coupling. Isolation is more important than avoiding the repetition of superficially similar code.
Soft encapsulation
  • The implementation of a component should not be exposed to other components.
  • For example: your component should not leak styles into the HTML tree fragments of other components; a component's HTML should not be directly included in the HTML for another component.
  • Complexity is a significant problem for large, adaptive applications. The more you can reduce the entanglement of your components, the easier it is to reason about the system.
  • Write small, independent components that are well documented to describe how the components should be used, and why specific CSS properties are needed in the implementation.
  • Do not assume that CSS is self-documenting.
comments powered by Disqus