Dave rounds up some of the acronymtastic ways of scoping your CSS now that we’ve got a whole new toolkit at our disposal.
If your goal is to reduce specificity, new native CSS tools make reducing specificity a lot easier. You can author your CSS with near-zero specificity and even control the order in which your rules cascade.
A few common gotchas when using BEM, and how to deal with them.
There’s a worrying tendency for “real” programmers look down their noses at CSS. It’s just a declarative language, they point out, not a fully-featured programming language. Heck, it isn’t even a scripting language.
That may be true, but that doesn’t mean that CSS isn’t powerful. It’s just powerful in different ways to traditional languages.
Take CSS selectors, for example. At the most basic level, they work like conditional statments. Here’s a standard if statement:
if (condition) {
// code here
}
The condition needs to evaluate to true in order for the code in the curly braces to be executed. Sound familiar?
condition {
// styles here
}
That’s a very simple mapping, but what if the conditional statement is more complicated?
if (condition1 && condition2) {
// code here
}
Well, that’s what the decendant selector does:
condition1 condition2 {
// styles here
}
In fact, we can get even more specific than that by using the child combinator, the sibling combinator, and the adjacent sibling combinator:
condition1 > condition2condition1 ~ condition2condition2 + condition2AND is just one part of Boolean logic. There’s also OR:
if (condition1 || condition2) {
// code here
}
In CSS, we use commas:
condition1, condition2 {
// styles here
}
We’ve even got the :not() pseudo-class to complete the set of Boolean possibilities. Once you add quantity queries into the mix, made possible by :nth-child and its ilk, CSS starts to look Turing complete. I’ve seen people build state machines using the adjacent sibling combinator and the :checked pseudo-class.
Anyway, my point here is that CSS selectors are really powerful. And yet, quite often we deliberately choose not to use that power. The entire raison d’être for OOCSS, BEM, and Smacss is to deliberately limit the power of selectors, restricting them to class selectors only.
On the face of it, this might seem like an odd choice. After all, we wouldn’t deliberately limit ourselves to a subset of a programming language, would we?
We would and we do. That’s what templating languages are for. Whether it’s PHP’s Smarty or Twig, or JavaScript’s Mustache, Nunjucks, or Handlebars, they all work by providing a deliberately small subset of features. Some pride themselves on being logic-less. If you find yourself trying to do something that the templating language doesn’t provide, that’s a good sign that you shouldn’t be trying to do it in the template at all; it should be in the controller.
So templating languages exist to enforce simplicity and ensure that the complexity happens somewhere else. It’s a similar story with BEM et al. If you find you can’t select something in the CSS, that’s a sign that you probably need to add another class name to the HTML. The complexity is confined to the markup in order to keep the CSS more straightforward, modular, and maintainable.
But let’s not forget that that’s a choice. It’s not that CSS in inherently incapable of executing complex conditions. Quite the opposite. It’s precisely because CSS selectors (and the cascade) are so powerful that we choose to put guard rails in place.
The fascinating results of Brad’s survey.
Personally, I’m not a fan of nesting. I feel it obfuscates more than helps. And it makes searching for a specific selector tricky.
That said, Danielle feels quite strongly that nesting is the way to go, so on Clearleft projects, that’s how we write Sass + BEM.
A walk down memory lane, looking at the history modular CSS methodologies (and the people behind them):
Feedbin has removed third-party iframes and JavaScript (oEmbed provides a nice alternative), as well as stripping out Google Analytics, and even web fonts that aren’t self-hosted. This is excellent!
Paul finishes up his excellent three part series by getting down to the brass tacks of designing and building components on the web …and in cities. His closing provocation has echoes of Heydon’s rallying cry.
If you missed the other parts of this series, they are:
A look at the technical details behind Firefly’s pattern library. The tech stack includes Less, BEM, and some React, but it’s Anna and Danielle that really made it work.
A good overview of ideas and techniques for structuring CSS and naming classes.
I’ve always loved the way that Edward Tufte consistently uses Bembo to typeset his books. Here’s a version made for screen and freely licensed.
Enduring CSS (not int the sense of “put up with” but in the sense of “long-lasting”) is a new book by Ben Frain all about writing and maintaining modular reusable CSS.
You can read the whole thing for free online or buy an eBook.
We tend to use a variant of BEM in our CSS at Clearleft. Glad to see that when we’ve hit these issues, we’ve taken the same approach.
I’m working on a project with a team of developers who are trying out the BEM syntax for their class names. I’ve tried BEM before, but I’m not a huge fan of underscores (for no particularly good reason) so I tend to use a modified version that avoids those characters. Still, when it comes to coding style—tabs vs. spaces, camelCasing, underscores, hyphens, or whatever—my personal opinion takes a back seat to the group consensus. And on this project, the group has opted for proper BEM all the way, and I’m more than happy to go along with that.
When it comes to naming a modified version of a component in BEM, the syntax looks like this:
component--modifier
That raises a question about how you then deploy that class name in your HTML. You could just use the modified name:
<element class="component--modifier">
But then in your CSS you’d have to repeat all the style rules for .component selector inside your rule block for .component--modifier selector. SASS could you help out here, especially with its “extends” functionality, but the final CSS is still going to containing duplicated rules.
The alternative is to keep your CSS lean and modular, and write your HTML like this:
<element class="component component--modifier">
Now you’ve taken the duplication out of CSS and put into your markup. It looks a little weird. But, on balance, it’s probably the lesser of two evils.
It strikes me that this pattern of always having the base component class name appear anywhere you have a component--modifier class name is something that you could programmatically check for. It should be relatively straightforward to write a lint tool that looks in the value of every class attribute and, if it finds any instances of foo--bar, checks to make sure that foo is also in there.
Sounds like it could be a nice little task for Grunt or Gulp. Maybe somebody has already made it.
Mind you, it seems that most lint tools out there are focused very much on enforcing a coding style for CSS and JavaScript—not so much for HTML. I worry that this reflects the mindset of many front-end developers who view CSS and JavaScript as more important than markup …which is a bit odd considering that CSS and JavaScript are subservient to the HTML document that they’re styling and scripting.