marketing ideologies
Our old front-end best practices are crumbling. Not the big ones like "make a site accessible", but the more practical ones like "no non-semantic class names" are under scrutiny these days. We need to fill that void and several people have sprung up to try and update our way of working. Their intentions are no doubt noble, but their methods are less so. I feel that too many of us are marketing our own approaches with the intent to convert innocent souls rather than properly inform the future generation of front-enders.
breaking good habits
Yesterday I ran into Harry Roberts' Breaking Good Habits talk. I feel a little bad singling out his talk for the purpose of my article, but it does illustrate quite well what I'm about to explain. Harry is in no way the only one guilty of these practices, in fact this article is just as much a confession about my own writing and a promise to try and do better in the future.
The title of the talk really captured my attention. I love it when people challenge popular notions, so I was eager to find out what magic Harry would uproot in his 30-minute talk. Imagine my disappointment when I found out it was just another oocss promo bit. The talk isn't really about breaking with good habits, it's about leaving behind some hindrances that stand in the way of people adopting the oocss ideology. It cleverly masks this (I don't think oocss isn't even mentioned once - though Nicole Sullivan is referenced a few times), but the bottom line is clear enough if you know a thing or two about oocss.
It's no secret that I'm not a big fan of css-based component ideologies (having written my own html-based component ideology that contradicts many of their best practices), but setting aside my preconceptions about oocss Harry's talk actually made a lot of sense. It's not so much that what he's saying is false or incorrect, I think the main problem lies with the things he (and many others) is not telling people when advertising his ideology of choice.
implications of oocss
One thing missing too often from talks or posts like these is context. I'm sure there are good use-cases for oocss-based projects, but this context is strangely missing in Harry's talk. Instead the ideology is sold as a general, can-be-used-everywhere solution, which it is definitely not. Basically three things are holding me back from using oocss:
- it merely shifts the weight from css to html and html changes are traditionally pretty expensive. If you're working on a project that offers perfect and easy control over the html this is not so much an issue, but otherwise you're setting yourself up for a major cms headache.
- abstraction of style can be done with sass or less. Abstracting css is a valid best practice, but it doesn't necessarily need to impact the html. If you can't use preprocessors or if you can't handle the impact on css filesize, this point is moot though.
- oocss doesn't cater for reuse across projects. Each template needs to be handcrafted based on the specifications and design of a particular project. While some abstraction can be carried over from project to project, the gain there is extremely poor. So in fact I believe that oocss is not modular, flexible, extensible and whatnot enough
I understand that it's not very beneficial to tell people this when hosting a talk on oocss, but it's a reality that cannot be ignored. If you're not telling people this, how can they make a good judgment when choosing the proper front-end methodology for their own projects?
some practical remarks
There are mainly two things that irked me the most when watching Harry's Breaking Good Habits talk. use sass/less for abstractions
/* the oocss way */ <div class="nav breadcrumb">...</div> .nav {...} .breadcrumb {...} /* the preprocessor way */ <div class="breadcrumb">...</div> .nav {...} .breadcrumb {.nav; ...} There are few reasons why you wouldn't want to use a css preprocessor these days. It's true that it impacts your css filesize, but after gzipping and further minifying (remove unneeded mixins and combine css selectors) the resulting css file the impact really is quite minimal, especially compared to the trouble you have to go through changing your html (an the cost of extra code there).
classes and ids are not purely for styling
This is not even about semantics, but about the nature of a classes and ids. While it's true that css makes heavy use of classes and ids, the class and id attributes serve a bigger purpose. They provide logical hooks for whatever script that wants to interpret your html code. That includes javascript, statistics and whatever other script running through your code. In the end it doesn't really matter that your news preview looks the same as your blog preview, if you want to track them separately in your statistics tool you need differentiators in your html code, which is exactly why we have classes and ids that describe the difference between those two instances. Need them styled the same way? Make a mixin ...
conclusion
Once again, I am the first one to admit that a lot of stress and work is involved when providing a solid context for what you're trying to get across. But we should realize that we're not marketing or selling ideologies here, instead we're trying to inform people about better ways to do their job. By not giving them all the information we're leading them to make the wrong choices, which in the end will set our entire industry back.
Even though Harry's talk was intended for an audience of professionals who can be critical of the information presented to them, the vimeo link can be freely shared and reaches a much bigger audience. Many of the people it will reach will only see the part of the talk that makes sense, without getting the full context and without knowing about the possible caveats of the promoted ideology.