Great comment! I pretty much agree whole-heartedly in everything you wrote!

I’ve been doing quite a bit of CSS fixing/updating for a handful of large complex websites lately. Some of what I am finding right along with what I am reading here.

Here is my view on this (think of me as an outsider looking into your CSS to fix or add something).

Method 1) Being very specific is OK as long as you are doing it all in 1 file and you maintain a nice single line grouping (like Fabrice mentioned).

Method 2) Using a generic method (sometimes with “Overrides” such as Roberts .side-bar .pre-amble) is a a great method for being efficient in terms of code size and reusability.

Working with 1) Use the CSS file like an index based on what page you are working with, find its reference and alter it.

Working with 2) Search the CSS file for the class name (or parent) that is applying to your element. As long as your class names/IDs aren’t super short or generic (like don’t name a class with less than 3 letters) it is pretty easy to find all the places where that class is referenced..and then to see what subtags are affected. Since there is less overall CSS, it is not too difficult to figure out what is going on.

Benefit of 1) The benefit of method 1 is that people who are very CSS minded tend to prefer working like this…and it allows for very specific control of everything, and you don’t have to crack open the HTML file very often.

Benefit of 2) The benefit is that you can change things on all pages at once without having to be specific. You can minimize your code and simplify the styling markup. (which I think was the point of this article)

Disadvantage of 1) You have to write a lot of CSS. You might will find yourself writing the same styling over and over again if you lock yourself into this method.
Example - (Real example from something I had to work on):

#sidebar-left .links-menu li#work.active a, #sidebar-left .links-menu li#work.active a:hover{background-position: 0px 0px;color: #fff;}
#sidebar-left .links-menu li#contact.active a, #sidebar-left .links-menu li#contact.active a:hover{background-position: 0px 0px;color: #fff;}


Disadvantage of 2) Requires that you are very clever in your overall structure and design. You have to carefully construct your HTML and your CSS to work together. You have to pay close attention to inheritance and use it to help rather than trying to defeat it. Doing all of this might take more time, and you might not be able to get something up and running in a hurry.

Whatever method you choose, please keep the following things in mind. These are the things that take lots of time and headache to sort out. (at least for me)

Please don’t mix and match these 2 modes of writing CSS. Tracing through the multiple degrees of generic to super specific tags is never a treat.
Please keep your stuff grouped (especially critical in method 1).
For both methods avoid multiple files. Put it all in one file and avoid browser specific hacks or include files. It is possible (although challenging) to write CSS without hacks.
For both methods, don’t put in style declarations that do nothing at all.
For method 2, don’t take it to an extreme. Don’t be afraid to use classes for grouping. Rather than putting generic styles on “li” for example, create a class that groups all the elements inside an unordered list. I.E.

.simple_list ul{...}
.simple_list li{...}


Then wrap your list

< div class=”simple_list”>
<ul><li>item</li><li>item2</li></ul>
</div>

Why didn’t I just use ul.simple_list {..} and then apply the style to the ul tag? Because now I have organized my CSS and my HTML in such a way that I can keep doing things to the .simple_list class of boxes, and it keeps things in a name space in for readability in CSS. So, if there are hyperlinks in there for example, I just add another .simple_list a{…}. It’s not super specific, but it’s not so generic that somebody might get lost.

Ok.. so you found me out. You can probably tell that my preference is method 2. Robert, I am in your camp on this. I think it just makes better use of the power of CSS and HTML. Also, badly written generic code is easier to troubleshoot than badly written specific CSS in my opinion.

For those of you who want to make something portable, just put a single ID or unique class at the base of the styling elements to be grouped. This will essentially create a name-space bucket for it (#container as Robert demonstrates). You don’t have to traverse all the way down to each element.

Ya know, I thought that the point of CSS is to make things more manageable (better organized) and to create separation. But, the way I see it, separation isn’t a benefit in itself. Separation is actually just a requirement so that we can do more things with the page content later.

If the end result of a CSS implementation is that you need Firebug just to figure out what in the world is going on, then we might as well run with the devil an do all inline styles so we can at least find everything in one place. We haven’t achieved manageability or separation in this case anyway.

happy coding to you!

- Jeremy

PS. Marco.. good point.

In theory, the more specific style rules, the slower it should be for CSS code as well. Then again, I think the difference is hardly noticeable from a performance standpoint.

CSS quite often tends to start out nice, compact and organised and then slowly but surely deteriorate into a mess, especially when lots of different people who all have their own way of working edit it. It takes some serious discipline, coding conventions and patience on the side of those who are in a hurry to prevent this from happening.

I write boxed CSS code. I don’t plan on switching soon. There are great advantages. I can install a forum or a gallery and reference the global CSS and style small parts of the gallery as opposed to fully styling it because there are no conflicts due to specificity. There cases where classes are not enough, especially when you use common terms that can be used by multiple applications for different things.

I wonder how much of this comes about because of the way Dreamweaver pre-populates the Advanced selector field when a page element is selected in Design View and the + sign to create a new style is clicked. Dreamweaver goes through the entire page hierarchy in naming the selector, an example of far too much.

But I think/hope that such scenarios aren’t that common, although I know they do exist. It seems they exist more in fairly large web sites and in communities.

Jeffrey Sambells ,

I think my examples are a bit too short to exemplify my point about reusage. The idea is, with .pre-amble for instance, is that many CSS properties will be the same wherever it is used. The gist is to focus on what is being general no matter where it is being used, and then code extra for exceptions. Kind of like this:


.pre-amble{
color: #f00;
font: bold 1.25em V eradna, Arial, Helvetica, sans-serif;
text-align: center;
margin-bottom: 1em;
padding: 0.5em 1em 0;
/* etc... */
}

.side-bar .pre-amble{
color: #000;
}


About having element names before classes: I find this very useful when I have general class names (like .help) where I might use a.help or img.help elsewhere in the markup. Using div.help leaves the clashes out of question that way.

I think the rule often quoted is start general and get more specific as you find the exceptional cases.

In the past, I’ve been burned because my CSS was not specific enough and the developer CSS overwrote my styles. This happened with my dropdown calendar. A developer’s styles made the calendar text so small that it was unreadable. Instead of the “Today” link being centered it was right justified. Then they complained that the problem was with my utility, and they were right, I needed to be more specific.

So while I agree with you for general page styles, when writing a utility that is going to be used by other developers, I have to protect my clients by being very specific with the CSS styles for that utility. If the developer needs to overwrite a style, they can do it by being just as specific. That requires them to intentionally want to make a change to the style of the utility.

I have noticed many people using code like:


HTML body #wrapper #nav {...}


Just to avoid using !important.

When I’m scanning through a CSS file !important will jump out at me as a “hack” but the above code will not stand out as easily. Seeing !important lets me know immediately what I’m dealing with.

In a perfect world we would avoid both, but as we all know the web is not a perfect world.

I agree that something like:

div#container div#header ul#navigation li{
float: left;
}

is redundant simply because ID’s such as #navigation only appear once in a document (according to spec) so having multiple ID’s in the rule isn’t really useful since there’s only one #navigation anyways. The only exception is if you’re using a dynamic CMS that keeps moving #navigation around in the markup (but if that’s happening then you’ve probably got other issues).

However, the example of

.pre-amble{
margin-top: 1em;
}

can often cause problems if it’s too vague. If ‘pre-amble’ is a class then I would assume there are multiple pre-amble classes scattered about the page, on different elements. Now you’ve said they should all have a specific margin but in reality the pre-amble in the sidebar will probably be different than the one in the main content area. In this situation, if there’s only one pre-amble, it might be better as an ID (the pre-amble of the content area) or, like you said, something like:

#content .pre-amble{
margin-top: 1em;
}

I’ve found a lot of the issue can be resolved by defining common classes that should always be associated with an element. For example, .first could be used to indicate the first in a set of elements (if you ignore advanced selectors). Then you can do:

#navigation li.first { }
#content p.first {}
etc...

but you’d never use .first all by itself.

The problem mostly arises when you’re working in a team so I guess the trick is to make sure everyone in your team is on the same page regardless of which methods you choose to use. Advantages of smaller file size, reusability and readability are great but reusability can also be a disadvantage if that’s not what was intended by the rest of the team. If it’s too reusable then you’ll be back to !important again.

I can see your point, but I use specification as a way of organizing my CSS. If I will only use a class called .warning in one section, I will still put at least the containing div id before it to remind myself where this style is being used, e.g.

#mainBox p.warning { ... }

instead of

p.warning { ... }