views:

372

answers:

9

In CSS, when setting a style on a div (for example) is there any benefit in including the 'div' other than to give it more precision for matching. Is it faster for the browser to render perhaps?

ie Is:

div.something { font-size: 1em; }

better than

.something { font-size: 1em; }

for any other reason than to narrow it down to only divs?

(The reason I ask is that I recently happened across a prominent site that includes the 'div's but most tend to not bother)

UPDATE:

Thanks for all the answers. The conclusion is that speed is a factor but not noticeable so worth ignoring. And the consensus on the best practice is that including the tag is cleaner - general rule should be to keep the CSS as 'tight' as possible for the required style.

A: 

Well if you like to have other tags with the same classname have another appearence then it might be a good idea to do it.

I always include the tag name for better readability and I'm sure that I won't override other rules if they share a classname.

Tomh
+1  A: 

Well I think the only purpose is like you said "to narrow it down to only divs". So that <p class="something"> should behave the same or not as the div...

Vinze
+1  A: 

I think this issue is very similar to the generally well known programming concept of scope limitation: you limit the scope of your variables and other resources to the minimum.

Similarly, if you know that a style will be only used with divs with that class, it makes sense to limit the "scope of the class" to divs. It makes less mess and makes your stylesheets somewhat more maintainable.

DrJokepu
Thanks to all who answered.So the concensus is that it is purely a scope issue.
Jo
Adding a dependency to the type of html-element does not compare well to scope limitation. You create a dependency that is unneccessary, rendering your html and stylesheet LESS maintainable. A change in the html suddenly requires a change in the css aswell. This is not good design.
Magnar
Magnar: I can hardly imagine any real-world situation where a substantial change in HTML does not require a change in CSS.
DrJokepu
But surely most changes are not substantial, Jokepu?
Magnar
True, most changes are not substantial. But I would call any change that changes a tag, say for instance, from a div to a p, substantial.
DrJokepu
If changing a div to a p is substantial, I have a hard time imagining any change that isn't. Either way, you have coupled your html and css so tightly that any change in the html requires a change in the css. That sounds like setting yourself up to failure to me.
Magnar
@Magnar: that's entirely subjective - you could equally have a case where a change in the HTML was negatively affected because a low-specificity style was applied to something it shouldn't.
annakata
@annakata Low-specificity css rules are a problem, but adding the element-type is not the solution. If my .price was changed to div.price, the probability for unintended matches are lowered only marginally. You would be much better off namespacing it with an outer #id.
Magnar
Umm, apparently we disagree here a bit. Oh, well. I guess if your approach of having broad style scopes works for you then you should do it that way. I will most certainly keep limiting them myself :)
DrJokepu
One last point: You should definately limit the scope of your style rules. My point is that you shouldn't rely on the element-type for this scoping - the hassle outweighs the benefits. You should use a wrapping #id instead. -Signing off ;)
Magnar
+5  A: 

Besides the different semantics of both selectors, read this: Speed of CSS

Gumbo
+3  A: 

if you want to use a class on more than just divs, you can just use a general class like

.something{}

but the more specific a class is, the more prominent it is, regardless of the order , i.e.:

#someID div.something { background: green; }
div.something { background: blue;}
.something { background: red; }

Since the first one is the most specific:

<div class="something"> this will be blue </div>
<div id="someID">
  <div class="something">
    this will be green
  </div>
</div>
<p class="something">this will be red</div>
naspinski
A: 

Adding div to the start of the selector creates an additional dependency between the css rule and the html-document. Changing the element type suddenly also requires that you change the css, for no good reason.

For the scenario where you need to specify the element type to discern between two rules, I would suggest changing the classnames instead. Don't expect that div to always be a div. It might make more sense as a p or fieldset or label.

Avoid unneccessary dependencies.

Low-specificity css rules are a problem, but adding the element-type is not the solution. If my .price was changed to div.price, the probability for unintended matches are lowered only marginally. You would be much better off namespacing it with an outer #id.

Magnar
+2  A: 

Adding the element selector (div) to the rule increases the specificity of the rule, making it more important than a generic class selector (.something)

It also makes your CSS more readable. If all your class selectors aren't prepend'ed with elements, it means your classes are ambigious, and could apply to any element. (This could be the intention, but more often it's not)

As stated above, there is a speed trade-off by using element names, but it's hardly noticeable.

ndorfin
A: 

Classes should be well structured, functional and atomic. Sometimes it's good to narrow it down to element.name if you think you'll have situations like

div.highlight {
    background: #FF00FF;
}

span.highlight, p.highlight {
    color: #FF00FF;
}

Otherwise you'd have to do something like

.highlight {
    color: #FF00FF;
}

div.highlight {
    background; #FF00FF;
    color: inherit;
}

I think, as a general rule of the thumb, that one class definitions should work for all elements applied to it. If there's a specific situation where you'd have to override the default definitions of a class that you should, for starters, at least define a new class so you don't break the presentation on other elements.

You'll also have to work out when to avoid such structural dependencies on your selectors, like

div#main div.section h1.title span.link { }

But it'd be better just to write

div#main span.link {}
kRON
A: 

It won't make a difference unless you reuse the class something somewhere else, and of course you have no conflicts that should be resolved using the CSS priority schema. If this is the case, div.something has a higher priority that .something as it is more specific. Take a look at Calculating a selector's specificity from the CSS2 Specification.

Leandro López