My professional life as a front-end developer started just before the Web Standards Project, everyone was working to make sure style was separated from content. It was drummed into me and I drummed it into you for many years, so it’s been difficult to forget.
For the last few months, maybe years, I’ve been reading about OOCSS or SMACSS or BEM or etc. and wondering why they felt a bit strange to me. I stumbled across an old article about The benefits of Web Standards to your visitors, your clients and you! and realised there was some conflict between those old guidelines and those that are written about now.
On semantically correct markup:
You should use standard HTML elements for your markup and avoid styling HTML elements to look like other HTML elements.
In my mind, the silent goal was to mark-up a page using the standard HTML elements and as few divs and spans as possible (basically, you were the winner if you used none at all). Structure was king and if you wanted to change that H2 to an H3 then they shouldn’t look the same.
One of the powerful aspects of CSS is that content can be re-purposed to suit your needs â€“ without changing a line of html code.
Ten years ago it was assumed you would be more likely to change your CSS than repurpose your content – you could completely change the look of your site without touching the HTML. CSS Zen Garden was born out of the old web standards movement and this ideal.
Perhaps today it is more likely that you will add to and update the content on your site but rarely add to the CSS – this has led to a best practice today that you should only style classes, never base HTML elements. It has eliminated some issues when developers or content editors might have to change the HTML or content without front-end being involved – document structure is no longer as important to the styling so the page design wouldn’t break, for instance if heading levels are changed.
Content and style finally separated.
My worry before writing this was that I was falling behind with or was out-of-touch with modern front-end development, but the fact is that all teams and projects are different and they just require a solution that works for them at that time. There will never be “The Best Way”, find what works for you and your team and go for it.