You are here:
  1. Home
  2. Blog
  3. Interwebs
  4. CSS: Using the Cascade

CSS: Using the Cascade

 |  Interwebs

Some of the biggest benefits of CSS include the space, time and bandwidth it can save you. Except that most web enthusiasts and developers — roughly familiar with the reasoning behind CSS — don’t actually bother to look into it properly so they end up bloating their stylesheets with unnecessary crap, thus defeating the point entirely. Take for example the following:

a.nav:visited { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 9px; font-style: normal; line-height: 14px; font-weight: normal; color: #FFCC33; text-decoration: none; }
a.nav:link { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 9px; font-style: normal; line-height: 14px; font-weight: normal; color: #FFFFFF; text-decoration: none; }
a.nav:hover { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 9px; font-style: normal; line-height: 14px; font-weight: normal; color: #FF9900; text-decoration: none; }

That’s 27 lines of CSS (whitespace removed to stop my blog stretching), taken straight from a live website. I picked this block of styling for two reasons: 1) it highlights repeated styling elements and 2) it shows the unnecessary use of a class, when this styling is supposed to be applied to all links (which means to take affect, class="nav" needs to be added to every link). There’s also the small ordering mistake, but that’s irrelevant at the moment.

We can actually use the “C” part of CSS to fix this bloat: the Cascade. This basically means that we can apply styling and allow the natural behaviour of CSS to apply this to ‘lower’ or child elements thus saving us time and space. For example in our code above we have one common factor, each ‘section’ of code is intended for the tag, the only difference between each is the colour. So, why not apply the common properties to a? That’s exactly what I’d do.

a {
font-family: Verdana, Arial, Helvetica, sans-serif;
font-size: 9px;
font-style: normal;
line-height: 14px;
font-weight: normal;
color: #FFCC33;
text-decoration: none
a:link {
color: #FFFFFF;
a:hover {
color: #FF9900;

We’re already down to 15 lines. Of course, I’m really anal and wouldn’t stop there. We don’t need to declare elements as “normal” if that’s their default behaviour, and the font properties can be combined bringing us down to 11 lines (and if we have already defined the font in body { }, this’d be 10):

a {
font: 9px/14px Verdana, Arial, Helvetica, sans-serif;
color: #FFCC33;
text-decoration: none
a:link {
color: #FFFFFF;
a:hover {
color: #FF9900;

Another way to stop yourself from repeating properties is to combine selectors. This can come in handy if you need consistant margins, e.g. if you want your lists, tables and paragraphs to have the same gap underneath them:

p, ul, ol, dl, table {
margin-bottom: 15px;

Not only have we saved the time of adding a superfluous class to each taking 16-17 lines out of the styling, but we’ve combined selectors to stop us from having to repeat properties.

Next week (or, whenever, you know) I’ll talk about using the cascade to create multiple themes based on the same structure.

Jem Turner +44(0)7521056376

23 comments so far

  1. Hev said:

    Thanks thanks thanks, Jem. I have been hoping that you might take some time and talk about CSS. I have been reading up on it, but I still have some problem. Now I am sure I will get it right. I enjoy how you explain things. It is so direct and to the point.

  2. AlisonW said:

    Apart from my always using fonts in em (not px – so wrong!) I’m guilty of expanding most CSS declarations rather than trusting the ‘cascade’ to work. Mostly it is historical – as I expect it is with others – in that early CSS browser support was very patchy and many browsers (msIE for a start) didn’t do the cascade thing, indeed there were charts showing which CSS declarations and options worked for each browser. I probably still have a set lying around here somewhere!

  3. Amber said:

    My CSS is a total shambles in terms of organisation. I keep fiddling with it to yield the correct results and overall it just makes it even worse. I feel I need a complete rehaul.

  4. Lew said:

    One quick tip, set your global font size to be 62.5% then use em for all your font sizes. The 62.5% global value will translate 1em to be 10px at ‘normal’ browser font sizing. 1.2em is 12px. Makes things much easier to work out. Also, I would always recommend resetting your css to get rid of the default values. The simplest way to do this is to just add something like the following at the very top of your css: * { margin: 0; padding: 0;)

  5. Sumaiya said:

    The problem with that, Lew, is that it messes around with forms elements. (See Reset Reasoning at People need to learn more about slimming down their CSS, I see a lot of this stuff online. @Amanda: Funny, Becky posted an article on relative font sizing yesterday as well. @Amber: I like to always organize my properties in the same order (positioning, typography, colors) and group the selectors by the way the page is set up – structural elements (i.e. wrapper, header, side, footer divs) have a section; then comes any special navigation; then the rest of the stuff in the order it appears on the page, generally headers, links, bold/italic, misc. classes, etc. I’ve read some places that people like to indent their CSS for each child element, so a wrapper and then indented styles for the header, content footer, etc. Perhaps that will help you some? On that note, is there a specific way one should organize selectors and/or properties? I know there’s TRouBLe for margins and LoVe HAte for links; anything else?

  6. Aaron said:

    And isn’t the original coding being used to style a navigation list anyways? Wouldn’t it be correct to make an id with the ul tag? Even though I knew this stuff already, it’s still helpful nonetheless. Now I’m working on making my layouts fluid.

  7. Dicle said:

    Jem, I have a problem with my stylesheet. I make new classes for navigation linking and image linking and etc. but the stylings are combined with my “normal”(unclassified) link stylings. Like I have blue background for normal text links and no background for navigation links but in the end my navigation links have blue backgrounds. (I hope I could explain it, I suck!)

  8. Jem said:

    @Dicle: To solve the specific problem you mentioned, in the class for the navigation links you’d need: background: none; If you have more problems, you can let me know or post at and someone will be able to advise :D

  9. Rachael said:

    No no no no no! For the love of God stop using pixels to size text! (not you, Jem, the person whose site you got this css from). grr… *rants*

  10. Lew said:

    @Sumaiya – I take your point, and am aware that forms can be a problem. I suppose (and the rest of this post is aimed at everyone, not just Sumaiya) one should always add the caveat that there will always be further tweaking beyond the reset needed, and testing in as many browsers/platforms as possible is the only way to truly get the desired results. On the other hand, I know successful designers who develop only for IE, taking the attitude that other browser users will just have to lump it. And they’re VERY successful web designers. So I guess it’s all about the real world. Yeah it’s nice to have cross-browser compatible, W3C compliant, fully accessible websites, but really, just how important is it. Would the BBC still be using tables for layout if anyone apart from developers gave a damn about compliance?

  11. Jem said:

    @Lew: Are you suggesting that anyone who chooses to code compliantly is not in the “real world”? I’m not really sure where this discussion on compliance and compatibility came from, but I would put it forth that cross-browser compatible, well coded websites are VERY important. I have just spent the past 40 minutes hacking about an atrociously coded heap of crap created by the developer in my job before me just to modify a line of text and an image in two identical sections across one website. This should have (and would have, had I coded it) taken me no more than 5 minutes. As for the BBC… their website is compatible in a multitude of browsers and they have a pretty extensive accessibility section that goes above and beyond the “requirements” of what one website should provide, so they’re hardly a good example of a company that don’t care.

  12. Lew said:

    First, please don’t think I’m ‘having a go’, I’m just trying to add to the debate. I’m saying that until a single unified standard for rendering engines (not the markup) is adopted it could prove to be a folly to follow this methodology or that methodology. The elegance of code is largely irrelavent to the vast majority of users and the managers who sign the web developers paycheque. In these days of broadband communication a few extra Kb in a CSS isn’t going to make any difference to a user experience, nor to server overheads. I seriously think more attention should be paid to image compression before worrying about small improvements in CSS file size. I’d rather a slow site that gave me the information I needed than a fast site full of pointless graphics and poor copy. As for the beeb, my point exactly! Here is a site that is fast, accessible, and global, yet hardly conforms to today’s web-development ‘ideals’ of tableless, liquid layouts etc. They achieve what users want and need without worrying about development purism.

  13. Jem said:

    I know you’re not having a go, I just wasn’t sure where this topic came from.. certainly I didn’t intend to create a debate on the benefits of cross-browser compaibility, etc (although I make no secret about following these ‘standards’.) Again, I disagree with your logic that a few Kb in a reduced stylesheet isn’t going to make a difference. OK, to me it’s irrelevant.. I might get a lot of visitors but I still have plenty of bandwidth to spare. However, to websites like Google where the unique visitor count is in the billions, just 1Kb or 2Kb file size difference could surely save them thousands? (Although obviously they’d don’t have issues footing their bills!) You talk about information filled sites as if the ONLY option is for them to be slow and boring and I think this “either this OR this” is a flawed argument. I have plenty of information on my site and it’s not slow :p At the end of the day, if there was any right or wrong answer to the debate about browser compatibility/etc it wouldn’t be a debate in the first place. I simply know that I can and will continue to code well, for multiple browsers thus gaining a wider audience and improving the web profit for “my” clients. Why risk alienating any potential buyer, no matter how big or small?

  14. Lew said:

    All very fair points and I’ve too much respect for you to risk this descending in to a flame war. I just feel it important that until rigorous standards are applied, and not just assumed, it is important to question everything. So just call me Devil’s advocate, and keep up the great work.

  15. Montoya said:

    Jem, I’m surprised no one has mentioned this yet, but I have a feeling that the original CSS you reduced was produced by an automated tool, NOT by hand. That’s the kind of code bloat the automated tools are usually guilty of.

Follow on Instagram