“There are differences between class and id. Class attributes should be used when you have more than one item on the page with the same class value. Conversely, id values have to be unique to a page.

When I first learned this, I figured I’d just always use class attributes so I wouldn’t have to worry about whether I was duping an id value. However, selecting elements by id is much faster than selecting them by class, so you can hurt your performance by overusing class selectors.”

Huh? I never use ID’s in CSS selectors, but I never experienced slow rendering either. I wanted to test if it’s stupid not to use ID’s.

First I wanted to see if it was even able to create a CSS that was hard to parse. Google has a nice article about writing efficient CSS selectors, so that seemed like a good start before setting up a test. In short there are 2 things that make a fast CSS selector:

• Make rules as specific as possible
  This means that div.content is faster than *.
  You have to be especially specific with the rightmost selector, since the browser reads CSS selector from right to left.
• Avoid (large) descendant rules
  An example of a descendant rule is div.content div.column1 div.columnHeader h2. Descendant rules are less efficient than rules with a single selector, like h2.

Test 1: setting up extremely inefficient CSS

The most inefficient selector by far is *. Combined with large descendant rules you get extremely inefficient selectors:

* * * * * * * * * {
	background: #ff1;
}
* * * * {
	background: #ff2;
}
* * * * * * * {
	background: #ff3;
}

I created a CSS file of about 20KB in size with 3600 asterisks characters (*). I combined it with a very large HTML file (1MB) with 9000 opening HTML brackets (<). Because I only wanted to test the CSS rendering, I added the following JavaScript to be able to load the CSS file on my local computer after the page was loaded.

	Load CSS
	

Results Test 1

All tests were done on my computer (Vista with Intel Duo Core @ 2.4GHz) except for IE7 and IE6. IE7 was tested on a Vista machine with Intel Core Duo SPU @ 2.67Ghz. IE6 was tested on my machine with Virtual PC and on a PC with Windows XP SP3 and a Pentium 3 CPU 3GHz.

The results show that browsers freeze for at least 2 seconds in order to render the CSS. So it is possible to screw up your rendering, but you really have to make an effort for it with large HTML files and unrealistic CSS selectors.

Test 2: setting up a more realistic scenario

In this test I created a more realistic scenario. I took an existing CSS file and altered it until it was 113KB in size and contained about 1050 selectors. I changed the CSS rules until the bulk of the code looked like this:

.Homepage .containerText {
	position: relative;
	margin: 15px auto 0px auto;
	width: 960px;
	background:#ffffff;
}
.Homepage .containerText .containerLeft {
	float:left;
	width:450px;
	padding:10px 20px 45px 10px;
}
.Homepage .containerText .containerLeft p {
	margin:0px 0px 5px 0px;
	color:#414a49;
	line-height:1.286em;
}

So most of the code in the CSS file consisted of descendant selectors with classes and hardly any tag names. The corresponding HTML page was also created from existing code and copy-pasted until the file was 107KB in size with almost 600 opening HTML brackets (<). Now we have a relatively large HTML and CSS, but not unrealistic. Once again I tested it in different browsers:

Results Test 2

All modern browsers responded so fast that I couldn’t really notice it needed rendering time. This means that the CSS file does not need any optimization by utilizing ID’s. The only browser that could profit from more efficient CSS selectors is IE 6. But since I don’t have to support IE 6 anymore, it’s not worth my time.

Conclusion

Writing fast CSS certainly will help some browsers on slow PC’s. But that is a minority of the users. So unless you have special requirements for your website, you’ll be better off focusing on writing logical, maintainable code than trying to get the browser to render a few milliseconds faster. There are some considerations though:

Being more specific

A few years ago I switched from writing .foo to writing a.foo. Adding the tag name in the selector gives me a better idea what I’m styling. Now I know that this coding style is also faster in rendering.

Descendant selectors

Descendent selectors (using more than one element in a CSS rule) are inefficient in rendering, but I won’t give that up. I like to be specific about what element I want to select in CSS. I rather write div.column1 div.article span.date than span.date. The latter is more efficient, but that only works with very small websites because only then you’d still have an overview of the all classes that are in the HTML code.

When I write JavaScript code I try not to ‘pollute’ the global namespace. I try to do the same with CSS by using descendent selectors.

If you need faster rendering, you could alter descendant selectors by making one class that incorporates the whole path. So you’ll get span.column1_article_date instead of div.column1 div.article span.date. Although it would render faster, it also has some drawbacks. Renaming a class afterwards is tedious work, the class names can become very long and the classes can be used outside it’s intended containers, so a class called div.column1_article_date could be used anywhere in the DOM and not just inside div with the class column1.

ID’s and JavaScript

I do use ID’s by the way, Not in CSS though, but for JavaScript for these reasons:

• Specific elements can be easily accessed in plain JavaScript with getElementById.
• If an element has an ID, I can be pretty surre that there is a bit of JavaScript attached to it.
• Using ID’s in your jQuery selectors makes the selectors less dependent on the current HTML structure. It’s easy to break existing jQuery selectors by removing a class in the DOM.

Related posts:

1. Too advanced CSS selectors
2. Hack: how to enable :first-child in IE6

Most of the time that’s not what you want. Using tag names as selectors can also make design changes troublesome if you have to add more divs and need to give it a different styling. But since IE7 we can use new selectors that help us to build much more delicate CSS selectors. Those new selectors are:

• Child selector: .parent > .child
• First child selector: .parent .child:first-child
• Adjacent selector: .sibling + .sibling
• First child selector: div:first-child
• Attribute selectors: div[id]

Now you can style the following HTML with just a single class:

HTML:

	This is some title
	Lorem ipsum
	Lorem ipsum
	Lorem ipsum
	Some body text with lots of lorem ipsums in it
	Some body text with lots of lorem ipsums in it
	Lorem ipsum

CSS:

.container span {
	font-family: sans-serif;
}
.container > span:first-child {
	font-size: 1.5em;
	font-weight: bold;
	font-family: serif;
}
.container > span > span {
	font-style: italic;
}
.container > span > span > span {
	font-weight: bold;
}
.container > span + span {
	display: block;
	margin-top: 0.5em;
}
.container a:nth-child(2) {
	font-weight: bold;
}
.container a {
	display: block;
	color: #f0f;
}
.container a:nth-child(4) ~ a {
	font-size: 0.9em;
}

The advantage is that you can, as you can see, style whole blocks of HTML code with just one class. In theory you could even use no classes at all. Without ‘class’-attributes on every element, the HTML code looks just a little bit more cleaner and readable. You can also use those and other selectors in javascript libraries like jQuery to select particular HTML elements. Since most libraries are cross-browser you don’t have to worry if a selector is or isn’t supported by a browser. Consider this piece of code in jQuery:

jQuery(".container a:nth-child(4) ~ a").click( function() {
	alert('hello world');
})

That’s all nice, but should I use it?

No. I use them some times, but I try to stay away from it if possible. The problem with these selectors is that they rely so much on the structure of the HTML that it becomes harder to change the HTML structure. If you take another look at the HTML and CSS that I showed as an example in the beginning of the article, it’s clear that you can’t add a few links or spans without having to change the CSS. Add some advanced jQuery selectors in the mix and you may have locked the HTML structure forever since no-one dares to change it.

Should I discard those new selectors then?

Not necessarily. Sometimes you just have no choice if you for some reason are not able to change the HTML. My personal guideline is that styling has to be predictable. So when you edit some piece of HTML code, the styling should behave as expected. That means that you don’t style your HTML in a way that the text-color of the 4th span is red.

So what can be styled predictable? If you ask me advanced selectors shine when the structure is relatively fixed. Lists are a good example. Just take a look at these code blocks below. The styling will behave normal, regardless what you do with the HTML.

HTML:

Lorem
Ipsum
Dolor

Sit
Amet

CSS:

ul.list li + li {
	margin-top: 10px; /* adds top margin to all list items except the first */
}
ul.list > li {
	font-weight: bold; /* styles only the first level list items differently */
}

Javascript:

jQuery("ul.list li:nth-child(even)").addClass("zebra"); // adds zebra striping to a list

HTML elements you can easily apply advanced selectors

Besides ul, you can style uls, dls, tables. That doesn’t mean that other elements should only be styled with classes. There are always some exceptions to the rule. Just let your common sense be the judge.

Related posts:

1. How to overcome the limits of CSS in Internet Explorer 6
2. For the sloppy clickers
3. Hack: how to enable :first-child in IE6
4. Alternative for :nth-of-type() and :nth-child()
5. What you can’t do in IE’s Quirks Mode