An Event Apart: Object Oriented CSS

by Luke Wroblewski April 5, 2010

In her Object Oriented CSS talk at An Event Apart, Nicole Sullivan shared ways to optimize CSS code and ideas for the future of CSS.

    CSS is a declarative language but there lessons it can take from object oriented languages
  • Developers should work with respect for the design. This makes code as beautiful on the outside as it is on the inside. Respect the original design vision.
  • CSS code is often too fragile. It can get ruined by the first person to touch it.
  • CSS requires an expert ability to just get started. There’s a very big learnign curve. It needs to support more then just expert developers.
  • Code re-use in CSS almost non-existent.
  • File size in CSS just keeps getting bigger as we continue to modify it.
  • Browsers have default stylesheets and they are all different. YUI reset.css levels the playing field across browsers.
  • Browsers ignore styles that they don’t understand. You can use this to your advantage.
  • Order matters in CSS. Class order doesn’t matter inline but does in the stylesheet file. IDs are stronger than classes. Inline styles will win over external stylesheets and those in the header. !important wins over everything.
  • Avoid inline, ID, and !important to allow cascade order to drive what gets implemented in CSS.
  • Aggregation of rules can still be used to manage differences without increasing code size.
  • Object-orientated CSS is a way of making CSS more powerful. A focus on the architecture of elements not just the attributes.
  • A lot of time has been spent on content within the CSS attributes. Object-orientated CSS focuses on selectors.
  • Visual semantics and code semantics need to be in harmony with each other. Most people only see the visual hierarchy so it usually wins out.
  • Reusing elements makes them performance “freebies”. Avoid duplication: don’t waste performance resources that can’t add value. If too modules look too similar to include side by side on the same page –they are too similar to include on the same site. Choose one!
  • Location-dependent styles isolate sections of sites to avoid conflicts but they create performance problems. As developers try to use things, if they change based on location –they will simply create something new that does not change. Elements should behave predictability in any module.
  • Classes can help provide the additional styles needed without relying on location-dependent changes. You can use semantic elements in HTML and style with header-named classes.
  • It’s easy to make a site fast on day one. It’s hard to make it fast after it’s been live for six months.
  • Use hacks sparingly. Don’t let them change the specificity of your code. Underscore and star are the best way to use hacks if you have to.
  • Define default values: don’t repeat this code in every object.
  • Style classes rather than elements unless you are defining defaults. This allows things to get reused in other places.
  • Give rules the same strength: use cascade order to overwrite previous rules.
  • Avoid specifying location: apply classes to the object you wish to change.
  • Encapsulation: don’t access sub-nodes of an object directly.
  • Avoid !important except on leaf nodes (no sub-nodes). This ensures things work deep in the DOM.
  • Set up an abstract class to handle general structure so you don’t have to repeat lengthy declarations across multiple styles.
  • Use the most abstract class name you can while staying semantic.
  • CSS wishlist: make it a better declarative language (need better ways to abstract reusable elements), make CSS easier for newbies.
  • Variables could make global changes easier. Could define up front and call within style declarations.
  • Prototypes could organize styles in patterns to reuse across a site.
  • Complexity can be abstracted out to the architectural level. There is no magic fix to make CSS easier but we can make it easier for beginners by requiring less code.