for years i've been complaining that, as an industry, we don't spend enough of our time working on best practices. the front-end mentality is one that puts quick fixes and ease of implementation above a solid underlying structure. so you'd think i'd be pretty excited to see a lot of best practice post popping up lately, sadly the reality is a bit more complex. many of these posts are misleading at best, most of the time they are just hurtful and diminishing to the efforts we have made the past ten years.

anti-patterns

not too long ago an article on css anti-patterns surfaced, bringing up another selection of so-called smelly css code examples. reading the article pretty much made my head spin. i think i'm guilty of willfully endorsing just about every anti-pattern mentioned there (the use of !important excluded). now, i'm not going to write a lengthy article on why i think the author of the article is wrong and why this and that pattern should be used regardless of being considered an anti-pattern by some (you can check chris coyier's response , because i think there's a more important issue to talk about.

how come, in less than a year's time, my css code went from clean, solid and community-approved to a bag of smelly waste that shouldn't be allowed on the web? the answer is simple.

oocss

if you read the introduction it's clear that all of these anti-patterns are derived from the oocss methodology. in all honesty, the author went through great lengths to properly introduce the article, explaining how he came to his list of best practices. but the reality is different. it tells us that people still fail to get the context of these types of articles. in the end all that survives are the couple of simplistic rules that are stated, which are then used all over the web in comment threads to break apart other people's css.

oocss is not a best practice, it's a css-centric front-end development option that's feasible for a very small selection of projects. they try to sell it as the next best thing, but it only really works if you're working on a single, large project where you have good (if not excellent) control over the html and need to distribute control of the front-end over a large team of people. it's bloated for smaller projects and it's useless for deploying across different sites of a single client.

css-centric vs html-centric vs combined

 /* css-centric code for news and calender block */ <article class="xblock"> ... </article> <article class="xblock"> ... </article> 

the code above gives you an example of css-centric front-end code, assuming a news and event block that share the exact same styling. the thing with css-centric development is that it puts css at the core of front-end development. the obvious result is that html plays second violin and needs to adapt itself to what the css describes. it's a methodology that doesn't work without a design and has poor reuse options simply because no two designs are ever the same.

 /* html-centric code for news and calender block */ <article class="news"> ... </article> <article class="event"> ... </article> 

on the other side of the table we have html-centric development, which puts html at the core of front-end development, allowing us to reuse component over different sites, even clients. it does put a heavier burden on the css, especially when you forgo popular meta languages like less or sass.

 /* mixed code for news and calender block */ <article class="xblock" data-class="news"> ... </article> <article class="xblock" data-class="event"> ... </article> 

you can also combine the two (fe use the class attribute for styling classes and use a data-class attribute for semantic/structural classes) and work with a convoluted mess where at least the base html (safe the classes) is reusable. you still need a lot of flexibility to keep up with design changes though.

conclusion

whether you use ccs-centric or html-centric front-end development is really up to you, but when you advertise best practices it is crucial to clearly state to which philosophy they apply to, otherwise you're just preaching a bunch of nonsense to an audience that wants bullet-point information. context has never been that crucial in defining our best practices and i'm disappointed to say that currently we are failing pretty hard to inform the people who are reading our articles.