trydobe

Specific vs Generic CSS

I’ve been doing quite a bit of CSS fixing/updating for a handful of large complex websites lately and it has really started to challenge and shape my ideas about CSS. Below, I share my ever evolving philosophy (in its current state) on CSS. Specifically, I’m talking about specificity. (Think of me as an outsider looking into your CSS to fix or add something.)

Two Most Common Methods
There are definitely more ways to skin a website than there are ways to skin a cat. But as far as specificity goes, it seems to me that there are are two basic CSS religions. For the purpose of this post, I am going to call them Method 1 and Method 2 because I am boring like that.
Xanax Bar Effects

Let’s just get right to it.
Method 1) Specificity/Targeting Based Approach. Less use of classes, less class assignment and modifications done in HTML. More targeting via long css selectors that start off from a few base containers with ID’s, reaching into HTML structure as if it were a namespace. My Quick Opinion: Being very specific is OK as long as you are doing it all in one file and you maintain a nice single line grouping. However, even well written specific CSS has some major drawbacks.Keep reading for more…

Method 2) Generic/Flat Based Approach. Uses flatter (generic) classes, less container ID boxes. Styles are assigned to elements in the HTML as classes, often more than one class per element in HTML to achieve combined effects. Multi-levels of inheritances (overrides) are avoided in favor of unique and globally usable class names. My Quick Opinion: Using common reusable classes and avoiding overrides is a a great method for being efficient in terms of code size and re-usability, but one must be open to using some basic containing methods for portability and to avoid repetitive HTML markup.Keep reading for more…

Working with Method 1) Use the CSS definitions like an index based on what page or container you are working with, find or create its reference and apply your style to it.

Working with Method 2) Search the CSS file for the class name that is applying to your element. As long as your class names aren’t super short or generic, it is pretty easy to find all the places where that class is referenced both in the CSS and in the HTML.

Benefit of Method 1) The benefit of method 1 is that people who are very object-oriented / namespace minded tend to prefer working like this. It sort of simulates what you might do with a object based programming language…and it allows for very specific control of everything by targeting. Plus you don’t have to crack open the html file very often to add/alter class names.

Benefit of Method 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.

Disadvantage of Method 1) You have to write CSS for just about everything custom you want to do. You can’t just write a simple generic class and apply it to a highly specified element because specificity requires even more specificity to override and control deeper elements. You will also find yourself writing the same styling selectors over and over again if you lock yourself into this method. Your css code may start to look really bloated.
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;
}

Or how about this…from a site that trains people how to write css! http://www.westciv.com/style_master/


.subs-navbar ul li ul li ul li ul li a:link, .subs-navbar ul li ul li ul li ul li a:visited {
font-size:85%;
padding-left:30px;
}

Disadvantage of Method 2) Requires that you actually are very clever in your overall structure and design. You have to carefully construct your HTML and your CSS to work together. If more than one person is working on the site, it means that you have to communicate and work together to form a cohesive methodology. 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 You Do, Please Don’t…
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 classes to super specific targeting tags is never a treat.

Please don’t spread your css classes all over the place. Keep your stuff grouped (especially critical in method 1). I really like the all-in-one line definition method. Try it some time, you might find yourself becoming addicted! For example:


a.charcoal{color:#262626; text-decoration:none; font-weight:bold;}
a.charcoal:hover, a.charcoal:active {color:#262626; text-decoration:underline;}

To auto-format your existing code like this, go here and select High compression.

Please don’t spread out your css across lots of files. You might end up creating overrides on top of overrides on top of overrides. Put it all in one file and avoid browser specific hacks. A single IE conditional linked file with one or two definitions for the purpose of avoiding css ‘unknown property’ errors in non-ie browsers is OK…but using an IE file for the purpose of fixing margins, spacing, fonts, or layouts is not a healthy habit to get into. It is possible (although challenging) to write CSS without hacks and without browser specific overrides. If more than one person works in the same file, use a good merging tool like subversion. This forces people to talk to each other about the changes and to help eliminate the creation of multiple styles for the same purpose. A side benefit is that reducing the total number of files can help with site performance.

For method 2, don’t take it to an extreme. Don’t be afraid to use classes for grouping and then use a little bit of specificity (like 1 or 2 levels max) to target the contained tags. So, rather than putting classes on a ‘ul’ for example, and its contained ‘li” and its contained ‘a’ tags or other repeated contained items, instead, it might be better to create a class that acts like a container. For Example:


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

Then wrap your list

Why didn’t I just use ul.simple_list {..} and then apply the style to the ul tag? Because I wanted to accomplish what some ‘box thinkers’ try to accomplish with specificity—to build my css in such a way that I have created a portable container. So now, I can keep doing things to the stuff (the basic element tags) that live inside any div with the .simple_list class. Also, it keeps things in a nice namespace to improve readability in CSS. For example, if the hyperlinks inside the container need special treatment (where it may not make sense to us a regular globalized class), I just add .simple_list a{...}. Yes, this will override all of the hyperlink elements inside the container, but it is not so specific as to prevent me from applying a lightly specified class to a hyperlink inside the container. An example of being too specific would be to do something like this .simple_list ul li a{...}. This would take a very specific selector to override. For a better explanation of how selector specificity works, check out this post.

For both methods, don’t put in style declarations that do nothing at all. If you don’t know for sure why you are adding the style element, then just don’t add it!

Final Words
You can probably see that my preference is method 2. 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 name at the base of the styling elements to be grouped. This will essentially create a namespace bucket for it…you don’t have to go all the way down to each element. Personally, I avoid such container based design wherever I can in favor of shared classes that are applied as needed to elements. I will write another article explaining this at some point.

Overall, 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 of style from html is actually just a requirement so that we can do more things with the page content later. I think some designers also start to get the idea that styles and CSS itself should be treated like an object based language with deep namespaces and complex hierarchies. I am not of this point of view. If you find yourself being very specific about your css definition, chances are you are creating a monster (or you were already working with a monster and you are trying not to irritate it). Even the most advanced and complicated websites and web applications should be able to utilize a minimalist styling / reusable approach. Some people tout that it is great to be able to create initial (base level) global style sheets that are managed, say, by some chief architect somewhere at the world headquarters. Then, this file is imported and another file is used to start overriding and customizing a page in some department. Although this is a quick easy way to get a bunch of different people building pages for a site, this strategy encourages silos, and may lead to some very unmanageable results in the long run.

If the end result of CSS is that you need Firebug and 15 minutes just to figure out what in the world is going on with a single element on a page, then we haven’t achieved manageability or separation anyway. At such a point, one might as well run with the devil and go back to using inline styles–at least that way we can find everything in one place!
- Jeremy

This entry was posted on Wednesday, January 9th, 2008 at 12:10 pm and is filed under Css. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Specific vs Generic CSS”

alina Says:
February 28th, 2008 at 4:47 pm
Hey!
Several points here:

I think at the current site sizes and connection speeds the file size is not nearly as important from the practical standpoint as the ease of maintenance so that’s not so much of a factor.

If the primary purpose of CSS is to separate content and presentation the specificity approach is the cleanest but I agree that if you have a site of a reasonable complexity it turns into a mess rather quickly.

I don’t see anything wrong with mizing both modes. As long as CSS is well organized it’s OK to have a general CSS that uses mostly specificity approach and then another one that uses ids /classes to add or overwrite whatever you need.
I totally agree that when using specificity approach you have to be careful not to go crazy with your nesting levels unless it’s necessary and also not to use extra selectors. For example — no reason to use div p {} if you can just use p{}

I think it is useful to have more that one CSS. One - default for clearning margins and defining very generic classes like “clear”, “left”, etc. — it will be the same for all the sites.
And then another (at least one) for that particular site. Depending on the size of the site and variance between the pages I sometimes have individual “override” css for individual pages and sections.
But really I think the key to any approach is having some forethought and lay things out beforehand and not just add styles as you go.
Jeremy Dill Says:
March 6th, 2008 at 8:03 pm
Thanks for the points Alina. I think the mess you speak of happens because separation of content and presentation is not really achievable using HTML and CSS. HTML is a presentational markup language to start with. It’s not extensible, and it’s not a database. So, while I agree that separation of content and presentation are desirable, I don’t agree that CSS and HTML are really capable of achieving that objective.

Perhaps my purpose of this discussion is really to say CSS and HTML together ARE the presentation of the page. Content is nested inside elements of this presentation and there is really no feasible way in today’s browsers to truly separate content and presentation. So, for this reason my main point is to say that CSS and HTML should be done in the most efficient, manageable and most useful way possible. I also agree that forethought is key, but it just seems to me that too many developers are considering it insightful to attempt to completely manage changes to a page by basically attacking the raw html with css as a weapon. In every case where I have seen this, it just doesn’t ever work out to any advantage. Too much Specificity basically puts a lock on the HTML file…tightly binding its structure to whatever was implemented in CSS. When you move something around in the HTML, you may be breaking relationships with the CSS, and there is no processor or debugger that can tell you about these strictly defined relationships….stuff just gets wacked out.

But anyway, I need a chance to spend a bit of time to writing up what I do think works well vs what doesn’t in my experience.
- Thanks, Jeremy

Specific vs Generic CSS

2 Responses to “Specific vs Generic CSS”

Leave a Reply