Writing Efficient CSS

Question

Sorry if this is waaayyy to basic of a question to be asked here. But here goes...

Ok so in another question something was being discussed, and this link was mentioned:

https://developer.mozilla.org/en/Writing_Efficient_CSS

In that article, they say some things I didn't know, but before I ask about them, I should ask this... Does that apply to CSS interpreted by Firefox? Forgive my noobness, but I wasn't sure what they meant by Mozilla UI. (don't hurt me!)

If it does apply, when they say:

Avoid the descendant selector!

The descendant selector is the most expensive selector in CSS. It is dreadfully expensive, especially if a rule using the selector is in the tag or universal category. Frequently what is really desired is the child selector. The use of the descendant selector is banned in UI CSS without the explicit approval of your skin's module owner.

* BAD - treehead treerow treecell { }
* BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { }

The descendant selector is just a space? And then what would the difference be between child and descendant? Child is an element inside another, but isn't that the same as descendant? OH! Shit as I'm writing I think I might have figured it out. A descendant could be a child/grandchild/great-grandchild/etc? And child is only one deep?

Sorry again for the stupid level of my question... just wondering, because I have been constantly using descendants in my CSS for my site. But yeah, if this isn't about Firefox then this whole question is pointless...

If its not about Firefox, does anyone have a link to an article explaining efficiency for Firefox or Browsers in general?

Answer 1

A descendant could be a child/grandchild/great-grandchild/etc? And child is only one deep?

Yes, exactly. Since a child can only be one deep, there's a much smaller space that the rendering engine has to recursively search to check if the rule matches or not.

And yes, that article is about both Firefox and browsers in general. Most (all?) of what is in it applies to any page rendering engine.

Answer 2

A "parent > child" is only one step down, whereas an "ancestor descendant" could be one or more steps down.

Even better is to use "#id" tags wherever possible such that there is less DOM searching.

Answer 3

The UI CSS is for styling the internals of the browser - the settings dialog, extensions interfaces etc.

Descendants and children are different, children are much more specific and result in much less having to be considered.

Answer 4

...as I'm writing I think I might have figured it out. A descendant could be a child/grandchild/great-grandchild/etc? And child is only one deep?

Indeed.

One thing I can add on the efficiency side of things is: Don't use * unless you really mean it. It's pretty intensive as rules go and most people could get away just specifying the elements they really want to target.

Answer 5

The problem with the child selector is that it's not as well supported. Of course, this might've been fixed on newer IE browsers.

In any case, when writing CSS for a webpage it isn't going to be that big of a deal. I doubt the fractions of seconds you'd save in page load would even be noticed. This article seems more directed towards people writing stuff for the actual browser, not websites.

Answer 6

First of all - the suggestions in this article are not for html pages - they are specifically for the Mozilla UI - XUL, so it may be best practice for XUL, but not for html.

Applying the CSS on an average HTML page is one of the quickest things than happen while loading the page.
Also, the article may suggest the fastest way to apply css rules, but at what cost? For example, they suggest not having more than one class per rule:

BAD - .treecell.indented { }
GOOD - .treecell-indented { }

That is almost outrageous. It may lead to quicker CSS, but who cares? Assuming you already have .treecell and .indented, following these suggestions leads to complicated logic, harder maintenance, duplicated css rules, harder JavaScript (which costs a lot more that CSS), etc.
They suggest not using the full richness of CSS selectors and replacing these selectors with flat classes, which is a shame.

Answer 7

O'Reillys "Even Faster Web Sites" has a whole chapter on this entitled "Simplifying CSS Selectors". It references your link on Mozilla.

I think two points are worth bearing in mind.

1. Yes, if you did this as far as possible, your HTML and CSS would be a mess of styles and possibly even more inefficient due to added file size. It is up to the developer to pick the best balance. Don't agonize over optimizing every line as you write it, get it working then see what can be beneficial.

2. As another commenter noted, it takes the browser milliseconds to figure it out how to apply your styles on page load. However, where this can have much bigger impact is with DHTML. Every time you change the DOM, the browser re-applies your whole style sheet to the page. In this scenario many inefficient selectors could make a visible impact to your page (perceived lagginess/ unresponsiveness).

Answer 8

The documentation for Google's Page Speed (a Firefox/Firebug add-on) includes a good page on efficient CSS.