CODEWITHSUNDEEP
htmlcss
ChrisP
ChrisP

Reputation: 10116

Are fully qualified CSS styles efficient?

In creating CSS styles one approach seems to be a fully qualified style such as

#pnlImage div.ipd-imageInfo div.ipd-tags span.ipd-tag

compared to a shorter definition such as

div.ipd-tags span.ipd-tag

which would uniquely identify the style as well. However, if the site is expanded or changed the 2nd style runs the risk of not uniquely identifying the element.

Is there a performance hit from fully qualifying a style, i.e., it is longer? Are there some guidelines/best practice references for style naming?

Thanks

Upvotes: 11

Views: 2002

Answers (7)

Syntax Error
Syntax Error

Reputation: 4527

I have a site where another designer used heavily qualified styles and maintenance is a nightmare. (the qualified styles are only one part of that)

Basically, you can't touch or simplify the html structure without it breaking half the styles, and the styles often don't cascade properly to new content additions. If you add new css you in turn have to qualify your new rules heavily or half of them end up overridden by some existing rule because it contains so much specificity.

So from a maintenance standpoint it's not efficient. Also not efficient from a typing standpoint either.

Upvotes: 1

Davy Landman
Davy Landman

Reputation: 15439

Although your question is about the performance, (and I would suggest, measure it..) I would really like to add that you should always try to use the shortest definition possible to identity the correct elements.

The reason is not the file size, but the ability to extend your site without altering the main css.

For example you've got this part in your html site:

<div id="Header">
    <h1>Css example</h1>
    <h2>Welcome to the css example site</h2>
    <p>An example page by davy</p>
</div>

and this is the css:

#Header 
{
    background-color: #ffeedd;
    padding: 1em;
}
#Heading h1
{
    font-size: 3em;
    color: #333;
}
#Heading h2
{
    font-size: 1.5em;
    color: #666;
}
#Heading p
{
    margin: 0 0.5em 1.5em 1em;
    font-size: 1.1em;
    color: #999;
}

And later on you'd get to a page where you'd like your header to have a different background.

Had you chosen to use div#Header in you main css file, you'd either have to change the html (which depending on your system might mean creating a different template/masterpage) to add an extra class, or create a more qualified css selector such as body div#Header.

Using the shortest selector you could still use div#Header { background : ... } to change your header. You can either create an extra css file and load that into your header on that page (if allowed) or add a style definition directly to your <head> section. The nice thing about this is your css file does not grow with selectors for each different page, and you can keep clear of classitis.

You could also use it to switch the sizing method of your page (static/fluid) so that one template/masterpage uses the default css, and the other derives from that template/masterpage and just links a css called FluidWitdth90.css to change the template to 90% width fluid layout.

Upvotes: 0

Ms2ger
Ms2ger

Reputation: 15983

You might be interested in David Baron (Mozilla)'s Google Tech talk.

Upvotes: 1

jason
jason

Reputation: 8918

Google (not a search, actually them) seems to think that it does cause a performance hit.

Also, the Mozilla foundation has an article "Writing Efficient CSS for use in the Mozilla UI" that outlines the possible performance pitfalls of CSS selectors in their browser(s), and how to optimize your style rules for their rendering engine. Their article has tons of examples of what's good and what's bad. Please keep in mind this is only relevant to their browsers, though.

There are also some benchmarks publicly available, about CSS selectors affect on rendering speeds:

I, however, think this is, for the most part, horse manure. You can effect FAR greater change on your page's loading/rendering speed by using some other simple optimizations. I believe that your sanity, and a well-organized code base should come first. If this were as big of a deal as some make it out to be, we'd all be back using HTML < 4 attributes (bgcolor=, border=, etc) to style our web pages.

Upvotes: 7

pmf
pmf

Reputation: 7749

Is there a performance hit from fully qualifying a style, i.e., it is longer?

Yes, on every dynamic change of the DOM-tree, the CSS-expression has to be rematched against at least some nodes. I doubt this will lead to any noticeable delay, though.

Your stated objective (making the selectors robust against changes to the page structure) is not quite solid: hardcoding intricate details about the site structure into the CSS will just mean that you'll have more statements to maintain and update when the page structure changes.

If it's under your control, stick with simple classes (even if you have more of them) and as few levels as possible (doing some relative sizing of fonts is the only use case where I have used several levels, and even this was somewhat superfluous). It just wastes too cognitive capacity to keep track of the page structure in your head.

Upvotes: 0

ChrisW
ChrisW

Reputation: 56113

I don't see how a theoretical answer is possible: the answer is implementation-dependent; so I suggest you profile it to be sure.

Upvotes: 0

nickf
nickf

Reputation: 546025

  1. Looking up an #id is fast.
  2. Looking up a tag is a bit slower.
  3. Looking up a .class is the slowest.

Starting your selectors with a faster lookup will reduce the number of lookups required for then next part. That is, if I wrote p.myClass, then the browser can very quickly find all the p tags and then it only has to loop through those to check for the class name.

That said, it would rate the maintainability of your CSS file higher than its rendering speed. Blah blah blah premature optimisation blah blah.

Upvotes: 5

Related Questions