On Specificity: What's the difference?

[shaneisme]

When big the big guys start throwing their weight around, I tend to listen. So when the guys at places like Medium and Github put their CSS style guides out there using BEM on crack I know I’m on the right path… but… whenever they bring SASS into it, they don’t use one of the core principles of the preprocessor: nesting.

Instead, they mention specificity traps and move on. But what’s the difference?

.block {
something: 100%;
}
.block--element {
something-else: black;
}
<code></code>

and this:

.block {
something: 100%;
.element {
something-else: black;
}
}
<code></code>

To me, they’re functionally the exact same thing, but I like the SASS version better.

I can see an argument that HTML templates might be easier to read by looking at the CSS classes alone, but that’s pretty thin.

Also, when you cry specificity, isn’t the first version in BEM functionally the same?

If I’m wrong, please let me know as I’m not seeing it…

P.S. – I can’t get “Block Code” to work properly for the life of me.

[__]

Well, in this version,

.block
    something: 100%
    .element
        something-else: black

.element is useless outside of a .block. One might intend this, but it does allow for hard-to-notice mistakes, while you know that .block--element is always going to work, even if you forget the .block parent. (Of course, forgetting the .block parent might be just-as-easy a mistake to make.)

they mention specificity traps and move on.

Meaning, .one .two is more specific than (for example) .not-two. So, if you wanted to override the styling in .two, just adding the .not-two class wouldn’t cut it. At the very least, you’d need something like .one .not-two and possibly .one .two.not-two.

using BEM on crack

TBH, this is exactly how I feel about it. I don’t like the way BEM looks, and I don’t like how crowded and convoluted it makes the markup. It’s not friendly. In my mind, it’s just a few steps away from inline styling. CSS has child/descendent selectors because that’s often the best way to find an element. I try really hard to never have more than one or two levels of nesting, but I there’s nothing inherently wrong with nesting.

Some styling shouldn’t depend on context. But some clearly should. I guess my biggest objection is that BEM dismisses that idea out-of-hand.

[shaneisme]

Some styling shouldn’t depend on context. But some clearly should. I guess my biggest objection is that BEM dismisses that idea out-of-hand.

Yeah that’s one of the issues I have with it too. I suppose I only nest when I want something to be dependent. Otherwise I keep things separated and further apart than BEM would allow for re-usability sake. Now that you put it this way, I like it even less!

You bring up some great points though I hadn’t thought about, thanks.

[shaneisme]

Here’s the style guide for Medium that got me thinking:

https://medium.com/@fat/mediums-css-is-actually-pretty-fucking-good-b8e2a6c78b06

And of course: http://cssguidelin.es/

[__]

CSS has child/descendent selectors because that’s often the best way to find an element.

On second thought, I should clarify this:

• using child/descendent selectors to find an element is wrong. In this case, BEM is the right approach (whether to use those multipart--with--dashes--classnames----------------- is a decision I leave to you —but keep in mind that, if the hierarchy really is irrelevant, then there’s no reason to describe it in the class name).
• using child/descendent selectors to describe an element is absolutely correct. This is where BEM fails.

edit

And of course: cssguidelin.es

I’ve read that before. All good points, and yet somehow, only tedious/ awkward/ obnoxious style rules fall out the other end. Seriously, I would hate working with him.

[shaneisme]

I had a thought, that I know isn’t original, but it came to me nonetheless.

Setting up a default style for a class, in fact all classes, outside any specificity is a good start. It’s like thinking mobile-first without any JS and then enhance up. So set up CSS with the style defaults (almost assuming they’d be used as a web component) and only use specificity and child/descendant selectors when needed in those very, well, specific instances.

I think this is what the guys I linked to are trying to do, I just don’t like their implementation (and I gather neither do you).

I mainly writing this out because I’ve developed a lot of bad habits over the years with CSS and I’m trying to retrain myself.

[__]

I really love normalize.css. After that, I like the idea of object-oriented css, especially the concept of separating “containers” from “content.”

[nixnerd]

I could have sworn that I read somewhere that nesting causes performance problems on huge projects when you get past a few levels deep. But… I don’t work on huge projects, so I quickly dismissed it.

IMHO, nesting makes for WAY cleaner markup and far fewer classes. I can’t possibly see how that’s a bad thing.

[__]

I could have sworn that I read somewhere that nesting causes performance problems on huge projects when you get past a few levels deep.

Well, sure. With selector complexity and page size, parsing starts to take longer and longer. Additionally, if the selectors are not well-thought-out (see my distinction above between “finding” and “describing”), maintenance and reusability go out the window.

You don’t need to be on a large project to appreciate this. Consider several smaller projects, which, with proper design, could be using basically the same stylesheets… but you end up having to rewrite them each time.

[nixnerd]

Well, sure. With selector complexity and page size, parsing starts to take longer and longer.

I guess this goes without saying but my point is the author thought it was a much bigger deal than I did.

Consider several smaller projects, which, with proper design, could be using basically the same stylesheets… but you end up having to rewrite them each time.

Right… and that’s why I hate uber specific class names. By nesting, often times, I don’t even need to assign class names! I’ve mentioned this in other posts but nesting allows me to set more flexible styling rules that don’t abuse specificity. The end result is much more semantic markup that I can often times reuse. Now, if I’ve got a very specific feature on one project, of course I’ll create a very specific class. But, that’s definitely the exception, not the rule.

I have noticed a lot of frameworks are very opposed to nesting and would rather have a BILLION classes for every dumb little thing they do. Seems insane to me and makes me want to die. So, I don’t do it that way.

[__]

totally agree.

[Author]

Posts