Of all the existing CSS methodologies I looked at, I took the most from BEM. There is much to appreciate in BEM:
- All elements get the same specificity; a class is added to all the elements.
- There is no use of type selectors so HTML structure isn't tightly coupled to the styles.
- It's easy to reason about what the parent of an element is, whether viewing the DOM tree in the browser developer tools or the CSS in a code editor.
However, the use of modifiers didn't really fit my needs. Although perhaps it wasn't preferable, my reality was that often I would need to override styles on a Block (in BEM parlance) depending upon some eventuality above it or by the side of it in the DOM.
For example, in the scenario where existing logic is already determined in an application, there may be a scenario where a class like contains2columns would be added above the item in question in the DOM and I would need to style changes based upon that, as opposed to changes directly upon the Block in question.
With BEM I couldn't find a clear way of understanding how that eventuality should be handled. Or how I could contain those kinds of overrides in the authoring style sheets. I wanted to define items and encapsulate all the eventualities that may occur on a particular item.
I also found the syntax confusing to reason over when glancing at classes. The differentiation between the way modifiers were written and the way elements were written was negligible. This would be an easy fix but it was still something that bugged me about it.
Finally, I realised I needed something extra. I wanted the ability to communicate and facilitate different contexts for a module. When a thing was created by the same piece of logic but could be used and styled differently in different contexts, I wanted a means of communicating that.
From SMACSS the main thing I found useful was dealing with state. I liked the declarative manner in which classes like is-pressed or attributes .btn[data-state=pressed] clearly communicated the state of elements.
OOCSS turned out to be the antithesis of what I needed. Whilst I appreciate what OOCSS can offer, it wasn't the solution to the problems I had. I didn't want to create a Lego box of styles that authors could use to build up visuals in a DOM/template. The abstractions OOCSS facilitated were inherently leaky which made maintenance problematic (change the value in one rule and you may inadvertently effect many elements), it was also difficult to find ways of dealing with varying viewports, for all the reasons already explained and the additional abstraction added further complications when on-boarding new developers.
Ultimately, by trying and failing, to varying degrees, with each of these existing solutions I finally fully understood my problems. Now it was time to tailor a bespoke solution. To paraphrase Pablo Picasso:
Good coders copy, great coders steal Pablo Picasso (sort of - sorry Pablo)
Walk with me.