I think it’s great if a CSS developer wants to learn the ins and outs of specificity, because it is an important aspect of how CSS works. But I’m going to put forth an argument here that CSS specificity is quite overrated and, in fact, learning about CSS specificity has the potential to degrade the quality of your code.
Who Says Classes Can’t Be Unique?
If you were to ask the average web developer to tell you the difference between a class and an ID, they’d give you the basic answer that I gave in this CSS Basics article: IDs are specific, and can’t be reused; classes are less specific and are reusable.
But many developers have taken this a step further. They reason that since the styles aren’t going to be reused, they advise you to use an ID selector. So IDs are basically reserved for unique styles that won’t apply anywhere else. This sounds fine in theory, but it is bad advice and quite silly really.
There is nothing wrong with using a class that only appears once in your stylesheet. It has basically the same effect as an ID. But when you think of the potential benefits that come from using a unique class, as opposed to a unique ID, there really is no sense in using an ID as the selector.
On its own, .element is exactly the same as #element. It doesn’t matter that the ID selector is more specific, because you’re not trying to override anything anyhow. And on top of that, the class has the potential for later reuse, and will be more likely to keep the natural cascade in place, thus keeping your code cleaner and easier to read and maintain.
Specificity Doesn’t Live in a Vacuum
CSS specificity is always relative to the rest of your CSS, and is not a relevant concept on its own. That’s why thousands of people write CSS every day without knowing much at all about specificity.
If you’ve created clean CSS that isn’t causing specificity wars (yes, this means you have to use OOCSS principles), then there’s no reason to use an ID selector, or any other selector that has high specificity.
It doesn’t matter that #element and !important have really high
specificity
override abilities
. It’s all relative to what else you’re doing in your stylesheet.
For example, compare this code:
.element {
color: blue !important;
background: green !important;
}
.element-2 {
color: blue !important;
background: green !important;
}
.element-3 {
color: blue !important;
background: green !important;
}
With the following one:
.element {
color: blue;
background: green;
}
.element-2 {
color: blue;
background: green;
}
.element-3 {
color: blue;
background: green;
}
Although the exact same selectors are used, and the exact same styles are being applied, it’s obvious that the first chunk of code
is “more specific”
has more weight
than the second. Why? Because each line uses !important. So if these two chunks of code competed with each other, the first one would win, regardless of the cascade.
But why should they compete with each other? They shouldn’t. You should do your absolute best to avoid using !important. Each of those examples, on its own (assuming no other CSS), will produce the exact same result. So specificity
(or weight, in the case of
!important)
is only relative to the rest of your CSS, and is not something that should really affect your CSS development much at all.
If anything, knowing that different selectors have different levels of specificity — which can often be confusing to beginners and even intermediates — should convince you beyond any doubt that OOCSS and its reliance on abstraction and class-based selectors is the superior option.
A Warning About “Learning” Specificity
In the introduction, I said that “learning” about CSS specificity could have a negative impact on your code. The reason I said that is because some may feel that giving styles higher specificity is a good thing. But it’s not.
That’s why I now strongly recommend OOCSS, which encourages using class selectors almost exclusively. Classes have low specificity, and they’re reusable on any element. If instead you choose descendant selectors (like article h2) and ID selectors, then you’re setting your code up to be far less efficient, and with a much higher chance for specificity wars.
Don’t believe me that the simple act of learning specificity can cause problems? Imagine you’re a CSS beginner and you’re creating a new web page. You know nothing about CSS, and think that the class selector is the only selector there is. You’re also aware that you can use multiple classes on a single element, but you don’t know of any other selector. The result? Although you’ll have a lot of classes in your HTML, you won’t have any specificity or cascade problems and your CSS will be easy to maintain. And this will happen even though you know nothing about specificity!
But on the other hand, if you know about varying degrees of specificity, then you’re more likely to use those more specific selectors, and use them improperly, as a crutch. And that’s where problems will arise.
No Blanket Statements
As is always the case, I am not making any blanket statements here; the “it depends” mantra applies here too.
There are rare circumstances where !important is necessary. There are circumstances, contrary to OOCSS thinking, where you have to use a descendant selector. There are cases where you’ve inherited a project and you don’t have the budget to make major changes, and it’s super practical to just use an ID selector. There are instances where a CMS dictates the markup to such an extent that understanding specificity is a huge benefit. And if you’re using a CSS preprocessor, then that could impact a lot of the concepts I’ve alluded to here.
But if you’re creating a project from scratch, and you have full control of the markup, then specificity will not matter. Specificity is under your control, and is always relative to the rest of the CSS. Therefore if you code with one level of specificity in mind in an object-oriented manner, CSS specificity will never be a factor and your code will be much cleaner and easier to maintain.
Source : http://www.impressivewebs.com/css-specificity-irrelevant
No comments:
Post a Comment