Last year, UI developers attended our first CSS3 Summit, a day chock full of great information. As thrilling as it was, some of wondered aloud at lunch whether implementation would be slow given that, in the real world, buggy browsers that can barely render CSS2.1 still prevailed.

Boy, were we wrong. Since last summer, we’ve been implementing CSS3 in all kinds of projects, especially when developing for smartphones – almost all of which run browsers that support CSS3, often better than traditional desktop browsers. It was a reminder that things move fast in frontend development. Training is crucial to our job, since new designs, styles, and techniques emerge virtually every month. Our businesses expect us to stay on the bleeding edge and know how to implement these new techniques to create successful products for our customers.

I looked forward to this year’s CSS3 Summit. Last year’s Summit was transformative. I was introduced to the work of Nicole Sullivan who’s developed what she calls Object Oriented CSS (OOCSS). Dubious at first, I assumed it was just the misapplication of a sexy new term to an old process simply to get attention – the way Ajax used to get applied to everything willy nilly. But I came around to OOCSS after trying to explain Sullivan’s ideas, and then presenting on them for our department and for a local user group, Refresh Hampton Roads.

Sullivan developed OOCSS out of her experience with large IT organizations where several (sometimes dozens of) UI engineers worked on shared projects across distributed environments making code control difficult. Sound familiar?

Large organizations also tend to promote specialization, creating silos between people involved in conception (such as designers, product developers and marketers) and those who actually implement the code that brings the concepts and Photoshop images to life on our customers’ screens. Sound familiar?

Sullivan was also intimately familiar with a major problem in the UI profession: a rampant shortage of senior UI engineers. As Sullivan pointed out, plenty of people can use tools such as Dreamweaver or ASP.net, but they often don’t understand the process and don’t know how to debug browser conflicts as a consequence. Plus, when developers rely on software to make decisions, the code isn’t always standards-compliant and it is rarely optimal for large-scale sites like ours. People who know how to correctly roll their own CSS and HTML weren’t easy to find, so Sullivan had to figure out a way to teach programming skills to people with no programming background. Out of that mix of experience, Object Oriented CSS was born.

What was most compelling about Sullivan’s story was that she worked for premiere IT organizations. I sat on the 20th floor, listening to her, thinking: “Here she is describing the very same problems we encounter. If IT companies have the same problems we have, whew! What a relief!”

It’s important to remember that the problem isn’t the print culture or the business culture or some peculiarity of our organization. These problems are endemic to organizations whether they’re IT-based or not. If that’s the case, then a lot of other organizations are in the same boat, including premiere IT organizations with a lot of resources. That means there are a lot of other smart people working on the problem from whom we can learn, who bring their time and energy to experimenting with ways to resolve the problems. We’d do well to listen up and see what we can learn and contribute to the bigger conversation.

This year, Sullivan talked about new insights from her experience implementing OOCSS in organizations trying to improve page download speeds. When she and a colleague studied the top-100 web sites, they found some egregious practices such as the fact that barely over half of them gzipped their stylesheets. Many sites had CSS files weighing in at over 100kb. Before Sullivan started working with them, Facebook had a stylesheet that tipped the scale as 1.5megs. Which sounds gasp-worthy until Sullivan pointed out that her research revealed that it’s the norm for large sites to have 750kb – 2meg stylesheets.

So, how can OOCSS help? Here are a dozen of Sullivan’s do’s and don’ts for avoiding CSS Kudzu:

1. Do create a component library composed of CSS objects that are like lego parts and can be mixed and matched to create your layout and theme
2. Do not rely on the cascade to generate the design
3. Do use classes, which are flexible, rather than IDs
4. Do use consistent semantic styles
5. Do minimize the use of selectors
6. Do separate structure and skin, container and content
7. Do learn to love grids
8. Do use CSS resets, customizing your favorite one to your site’s needs. Remember, some CSS resets are chain saws when you really need a nail clipper
9. Do extend objects by applying multiple classes to an element
10. Do not attach style to elements, style them only for exceptions
11. Do not use location-dependent styles
12. Do not sprite every image together, separate them into like images, and order them vertically instead of horizontally

Have a question? Need more examples? Looking for resources? Want to geek out over Object Oriented CSS (OOCSS), UI development or UX engineering? Write me at kelley.walker@dominionenterprises.com