On HTML and CSS best practices

Written by Harry Roberts on CSS Wizardry.

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

Best practices are exactly that; best. Not ‘better’, not ‘good when…’ or ‘best if…’, just best. They’re always the best, no matter what.

This is something I learned whilst undertaking the single biggest project of my career so far; the complete (and not-yet-live) rebuild of one of BSkyB’s most trafficked websites. For years I’d been working on medium-sized projects where I strove to use as few classes as possible, my CSS was so elegant and hand-crafted and everything used the cascade. I thought it was beautiful.

I found my old approach isn’t best practice when working on a big site, therefore it’s not best practice at all… You can scale down the big site mentality to smaller builds, you can’t scale up small site mentality to bigger ones. With this in mind, how you’d build bigger sites is best practice, how you tend to build smaller sites is typically (though, as ever, not always) based on fallacy and myth.

I recently rebuilt my friend Sam’s design portfolio site. Typically I’d have used IDs everywhere, not used any OO and not really paid much attention to the length or efficiency of my CSS selectors. This would have worked but only because the site is small. Any attempts by Sam to scale the site up, add pages, move components or alter the layout would have been hampered by these methods. Instead I decided to apply big-site mentality and dropped any IDs, used an OO approach and made sure every component is reusable. The resulting code is incredibly flexible, very efficient and still looks nice.

• OOCSS is always best practice.
• DRY is always best practice.
• Efficiency is always best practice.
• Maintainability is always best practice.
• Flexibility is always best practice.

It doesn’t matter if you’re building the next Facebook or if it’s just a site for the builder down the road; best practice is always best. You might not notice an inefficient selector on a small site, but it doesn’t mean that it’s not still inefficient. Just because you don’t notice something it doesn’t mean it’s not still happening.

Build every site like it’s a 1000 page behemoth because then it can scale; it may never need to, but it can. Building every site like it’s a piece of art, using convoluted selectors and rigid, ID ridden code, it can never scale, even if you want it to.

Your code might look like the Sistine Chapel, but if it’s a chore to maintain, or you find you can’t pick up a component and drop it anywhere with zero worry, then it’s not powerful. Code is about power before prettiness. You might feel dirty at first, but when you realise how nicely things fall into place using proper best practices you’ll see the benefits.

The only person who cares how pretty your code is is you. Your users want fast UIs, your clients want reliable builds and you and your team want code that is easy to maintain 6 months and a dozen client mind-changes down the line.

Best always means best, it has no caveats or conditions.

Further reading

• Our Best Practices are Killing Us by Nicole Sullivan
• OOCSS.org

N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…

By Harry Roberts

Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.