Things I wish I’d known about OOCSS a year ago

One of my favorite interview questions to ask is this:  If you could go back and do your last project over, what would you do differently?  Here is my answer.

18 months ago I went to my UEX lead and my boss with a pitch:  Use Object Oriented CSS to build our new web application. They agreed it sounded like a good idea, so we went forward.  Ultimately that was the right decision I think, and for many of the reasons that Nicole Sullivan will volunteer.

If you don’t know what it is, OOCSS is a form of DRY for front ends.  Websites have repeated patterns in them.  Some of them overt, some subtle.  With a single CSS file for the site, and the same HTML fragment to represent the same concept, you only have to get it working right one time, and then people who don’t live and breathe front ends can be productive while changing the site.  You just compose the existing rules and things happen.

That’s the theory at least.  In practice things are not that rosy.  It’s hard to avoid turning OOCSS into widgets, and every new piece of UI has a tendency to turn into a renegotiation of what the phrase “look the same” means.  The widgets look just a touch different every time you display them.  Over here it’s big.  Over here make it narrow.   Over there add a little bit of extra information.  Over here make it show extra information.  Can’t you just user a bigger icon over in this spot?

It’s not that you can’t do these things, but the Old Way made it easy answer these questions.  What it didn’t answer was “Why don’t they look the same in these two spots?”  OOCSS means that mostly you solve a problem once and it stays solved.  Mostly.

In practice you get regressions.  Different teams fix different bugs, and they break things other people just got done fixing.  It leads to some big frustrations and some hard feelings.

So How Do You Fix It?

You can’t expect people to look in 12 places to make sure they haven’t broken anything.  And you can’t expect people to make things look identical in 12 places.  You can try, but I assure you it won’t work.  So what do you do?

Put all 12 ‘places’ in one spot.

It’s so simple that it seems stupid, in that way that makes the brain slide over it when brainstorming for a solution.  If a repeated meme has subtle variations for different occasions, just manufacture a situation where they all appear contiguous to each other.

Build a fake page with fake data.  Don’t rely on fake data on a real page, that’s too diffuse and hard to maintain.  Build a proper fake ‘portfolio’ page, and express the full range of patterns.  Short text, long text, missing bits, etc.  Put it where only the developers and testers can find it, and expect them to refer to it when modifying the CSS.

Push Back, With Examples

The idea was sound.  Making a million ‘exceptions to the rules’ completely erodes that idea, in ways that are quickly worse than having done nothing at all.  Some people need a picture to explain to them that they’ve become unreasonable.  The thing is that sample pages you just wrote is a powerful demonstration of whether things have gotten ridiculous.

Repeated HTML is better than repeated CSS

One declaration in CSS and one in HTML is too DRY for the real world.  It gets very hard for the developers to understand, and templating engines don’t like deeply nested templates anyway.  Denormalize your HTML when it seems right to do so, but keep a single set of CSS rules.

I’m currently writing some extremely simple tools to facilitate doing just these things.  I’ll keep you posted when I have something code and more screenshots to show for it.

About innerjason

Software Developer
This entry was posted in Development and tagged . Bookmark the permalink.

1 Response to Things I wish I’d known about OOCSS a year ago

  1. Pingback: Passive Testing | Go First

Comments are closed.