div#name vs #name

Go To StackoverFlow.com


I know that in a stylesheet div#name and #name do the same thing. Personally I've taken to using div#name for most styling I do, with the reasoning that it's slightly faster, and means that I can identify HTML elements more easily by looking at the CSS.

However all of the big websites I seem to look at use #name over div#name (stack overflow included)

In fact I'm finding it very difficult to find many websites at all that use div#name over #name

Is there some advantage to doing #name that I'm missing? Are there any reasons to use it over div#name that I don't yet know about?

2012-04-03 22:11
by Sean
#id is way faster than div#id in javascrip - qwertymk 2012-04-03 22:18
@qwertymk Reference? That would seem to be a bug - Nicole 2012-04-03 22:25
Where would div#id syntax even be used in a pure js context, @qwertymk - paislee 2012-04-03 22:26
@NickC: I think qwertymk might be referring to jQuery, where $("#id") will simply call document.getElementById(), while $("div#id") will do a DOM traversal - hammar 2012-04-03 23:29
No, #id is faster than div#id, the reason being that #id simply has to find an element with the id and div#id also has to check if it's a div (browsers process selectors in reverse). Also, in jQuery (and most other JavaScript libraries), #id is optimized to document.getElementById(id) -- really fast -- while div#id has to invoke the selector engine - Peter C 2012-04-04 02:53
@NickC: I concur with qwertymk remark wholeheartedly; div#id is called an overly qualified selector because of the additional overhead at rendering (rather than going "find #id and apply style" it would work like "find #id, check if it's a div and apply style". This also applies to classes since rendering engines process selectors are right-to-left, and an efficient css selector is very different from an efficient css-style selector you'd use in, say, jQuery. Dig in: https://developer.mozilla.org/en/WritingEfficientCSS and https://developers.google.com/speed/docs/best-practices/renderin - o.v. 2012-04-04 06:18


Since ID's have to be unique on the page, most ID's you'd run into would only ever appear once in your style sheet, so it makes sense not to bother including what element it would appear on. Excluding it also saves a few characters in your style sheet, which for large sites which get visited millions and millions of times a day, saves quite a bit of bandwidth.

There is an advantage to including the element name in the case where a division with ID "name" might appear differently than a span with ID "name" (where it would show a division on one type of page and a span on another type of page). This is pretty rare though, and I've never personally run across a site that has done this. Usually they just use different ID's for them.

It's true that including the element name is faster, but the speed difference between including it and excluding it on an ID selector is very, very small. Much smaller than the bandwidth that the site is saving by excluding it.

2012-04-03 22:16
by animuson
What about div.name vs .name ? (guess I should have included this in the original question - Sean 2012-04-03 22:19
The speed at which CSS can be processed in most modern browsers still makes the hit for excluding the element name fairly small. I personally don't include element names on most of my classes for flexibility, so I can apply those styles to any element that might be more semantically fit. If you design it correctly, it works more efficiently - animuson 2012-04-03 22:21
Ok thanks for the clarification, makes sense - Sean 2012-04-03 22:25


Since the div part of div#name is not required (because ID are unique per page), it makes for smaller CSS files to remove it. Smaller CSS files means faster HTTP requests and page load times.

And as NickC pointed out, lack of div allows one to change the HTML tag of the element without breaking the style rule.

2012-04-03 22:15
by paislee
duh hadn't taken that into consideration, I'm guessing that div.name is still faster than .name though - Sean 2012-04-03 22:17
@SeanDunwoody See the edit to my answer - Nicole 2012-04-03 22:21


a matter of code maintainability and readability.

when declaring element#foo the code-style becomes rigid - if one desires to change the document's structure, or replace element types, one would have to change the stylesheets as well.

if declaring #foo we'll better conform to the 'separation of concerns' and 'KISS' principals.

another important issue is the CSS files get minified by a couple of characters, that may build up to many of characters on large stylesheets.

2012-04-03 22:18
by Eliran Malka


Since an id like #name should be unique to the page, there is no reason per se to put the element with it. However, div#name will have a higher precedence, which may (or may not) be desired. See this fiddle where the following #name does not override the css of div#name.

2012-04-03 22:19
by ScottS


I would guess that including the element name in your id selector would actually be slower – browsers typically hash elements with id attributes for quicker element look up. Adding in the element name would add an extra step that could potentially slow it down.

One reason you might want to use element name with id is if you need to create a stronger selector. For example you have a base stylesheet with:

#titlebar {
     background-color: #fafafa;

But, on a few pages, you include another stylesheet with some styles that are unique to those pages. If you wanted to override the style in the base stylesheet, you could beef up your selector:

div#titlebar {
    background-color: #ffff00;

This selector is more specific (has a higher specificity), so it will overwrite the base style.

Another reason you would want to use element name with id would be if different pages use a different element for the same id. Eg, using a span instead of a link when there is no appropriate link:

a#productId {
     color: #0000ff;
span#productId {
    color: #cccccc;
2012-04-03 22:31
by gilly3


Using #name only:

Well the first obvious advantage would be that a person editing the HTML (template or whatever) wouldn't break CSS without knowing it by changing an element.

With all of the new HTML5 elements, element names have become a lot more interchangeable for the purpose of semantics alone (for example, changing a <div> to be a more semantic <header> or <section>).

Using div#name:

You said "with the reasoning that it's slightly faster". Without some hard facts from the rendering engine developers themselves, I would hesitate to even make this assumption.

First of all, the engine is likely to store a hash table of elements by ID. That would mean that creating a more specific identifier is not likely to have any speed increase.

Second, and more importantly, such implementation details are going to vary browser to browser and could change at any time, so even if you had hard data, you probably shouldn't let it factor into your development.

2012-04-03 22:15
by Nicole
On reflection the whole "it's faster" arguement with regards div#name is a little stupid. However (and I should have put this in there) in my mind I also mean div.name is faster that .name which makes more sense as this might drastically reduce the HTML that the browser has to search through before finding all the elements to match to the styl - Sean 2012-04-03 22:28
Having said that I have no idea what kind of savings this would amount to (they are probably negligible - Sean 2012-04-03 22:30


I use the div#name because the code is more readable in the CSS file.

I also structure my CSS like this:

    margin: 0;
    padding: 0;
    padding: 10px 0;
    padding: 0 10px;

So I'm starting generic and then becoming more specific later on.

It just makes sense to me.

2012-04-03 22:30
by Chris Cannon


Linking div name: http://jsfiddle.net/wWUU7/1/





<div name="DIVNAME">Hover This!</div>

List of Css selectors: http://www.w3schools.com/cssref/css_selectors.asp

2013-08-25 15:30
by Jenei Tamás