Is element-specific CSS selector bad?

Question

Is p.error better or worse than .error?

I have read that element-specific selectors are bad and should be used only if really needed but noone seems to know why. I mean I do understand that .error is better for code reuse, but is there somekinda specific reason why I shouldn't address class with element always?

Answer 1

Having a very specific selector will not amount to bad performance, but if there are a lot of declarations applicable for an element, then the performance will take a hit. The only concern otherwise is that it increases the no. of bytes to be downloaded for loading the stylesheet. Trust me, Every extra character in HTML passed is evil and will amount to lower page load speed.

During CSS cascading is applied by modern-day browsers, the following is the process that occurs for each CSS property for each web page element:

1. Gather all the declarations for the property from all the sources. This includes default browser styles and custom user style, as well as author style sheets. If there is more than one, proceed to 2.

2. Sort the declarations by importance and origin in the following order (from lowest to highest priority):

   • user agent style sheets (default browser styles)
   • normal declarations in a user style sheet (a user’s custom style sheet)
   • normal declarations in an author style sheet (web page style sheets; external, embedded, and inline styles)
   • !important declarations in an author style sheet
   • !important declarations in a user style sheet

   The one with the highest priority wins. If more than one have the same priority then proceed to 3.

3. Sort by selector specificity. The one with the most specific selector wins. If no clear winner, proceed to 4.

4. The one that comes last in the source wins!

If the cascade does not set a CSS property on an element, then the browser will fall back to using an inherited property from the element’s parent (this only happens for some properties), otherwise the property is set to the CSS default value.

According to the above process, if you use a lot of more specific selectors, there would be a choice made after atleast 3 levels deep. Hence, the more the no. of declarations which might be applicable to an element, the lower the performance would be.

So, You must as specific as it makes sense to be.

Answer 2

no it's not bad, but it may not always be necessary

tools like Google's PageSpeed and YSlow! refer to these type of selectors as being "over qualified" perhaps that's where you're hearing the "it's bad" part from - reading material

take for example p#myid - an ID should always be unique on a page anyway, therefore there is no need at all to qualify it with the p element. an ID already has the highest weight when specificity is being counted so again it's totally redundant to add the extra part to try and add more specificty.

However with class names like your example it can sometimes definitely be desirable to add the qualifier as you may want the class to be re-usable on different type elements but have different properties depending on if it's a div or a p for example, the "qualifier" then makes the selector slightly more specific

.error {background: red; margin: 5px;}
p.error {margin: 2px;}

The code above means you can use the error class on any element and it will have 5px margins however if you set the error class on a p element the second selector is actually doing something, it's over-riding the first's margins but still getting the background color

So they do a job, but too often you see too many people over qualifying all their elements when it is not necessary.. for example if you're only ever applying that .error class to a p element then you wouldn't need the second selector.

The rule of thumb is to make the selector unique as quickly as possible starting from the right side of it.

Answer 3

As a general rule of thumb, the less selectors a browser has to evaluate the better.

p.error isn't necessarily "worse" than .error, if .error is used for multiple tags. e.g. div.error (see a foot note at the bottom).

But if it's only used on a paragraph anyway, then having p.error is just making the browser work harder i.e.

First it will have to find all elements with the class attribute error and then filter these by only having tags that are p.

Here is some interesting reading on Optimize browser rendering on Google's Page Speed site.

---

Foot Note

However if you need to use a class on multiple tags, it's probably best only to put in the css styles which apply to those tags instead of trying to separate it. e.g.

.error
{
   color:red;
}

h1
{
font-size:2em;
}

p
{
   font-size:0.8em;
}


<h1 class="error">Bad Heading!</h1>
<p class="error">bad!</p>

So that kind of defeats the need to prefix classes with tags anyway.

I hope this helps!

Answer 4

The reason is specificity. For example...

• +1 each access by class
• +1 each access by tag
• +10 each access by ID
• etc.

So, if you have a class and a tag access, that style has a specificity of 2 (1+1).

Later, if you're trying to style all .error elements, but you have a conflicting style in the p.error elements, the higher specificity will win. This may cause some headaches down the line. That is why you may not want to always use tag+class.

(That being said, specificity solves many more problems than it creates, and is generally regarded as Pretty Awesome.)

Answer 5

.error is more efficient than p.error .

To understand why this is more efficient I recommend you read this article over at css tricks.

Answer 6

CSS selectors are read right to left. So p.error has one additional step to .error. This may result in a smaller set or not - depends on your markup.

However, this is a micro micro optimization. There is not going to be a performance hit unless we're talking about a massive amount of selectors.

Here's a great article on CSS selectors that elaborates on how they are evaluated : http://css-tricks.com/efficiently-rendering-css/