What put the “cascade” in the CSS?

In our beginning steps as web design gods we’ve begun to see that CSS is a wise and good way to create rock-solid styling that is easy to update and separates style from content. Stating the obvious: having external CSS keeps our HTML as simple as we can, and the benefits of having one CSS file to tweak instead of style tags in sprawling markup should be self-evident (just look at the [1] CSS Zen Garden if you haven’t already done so. One HTML file; a legion of CSS, switchable with a click. Who wouldn’t want such power?).

Style Rolls Downhill

CSS, as just about everyone should know by now, specifically refers to the system of style rules that are contained in external files (usually with a .css extension) that can be attached to HTML files that then control display of tags and classes in that HTML file. For example, if one wants to style all H2 headings 48 point Palatino, all that’s conceptually needed to do is to define that style in the external CSS file and then attach that file to all HTML as appropriate. Every H2 tag in every HTML file that this notional CSS applies to will be 48 point Palatino, moreover, all that’s needed to do to change the H2 tags in all attached HTML is to change the H2 definition in the CSS file.

However, particularly for tyros, what exactly the cascade amounts to is poorly defined. Does it refer to the classic stylesheet application sequence:

1. Browser style sheet;
2. User style sheet;
3. Author style sheet.

Well, that’s part of it. The true center of the cascade has to do with priority of CSS elements.

A Matter of Priorities

The “cascading” part of CSS is mostly concerned with what style implementation overrides what; certain style implementations have priority over other styles and will override style specifications of a lower priority. In the above list, Author-generated CSS will override User styles, and User styles will override the Browser’s default style.

Within the standard, the following order applies (from least important to most important):

1. External styles have lowest priority;
2. Embedded styles will override externally-defined styles;
3. Inline styles will override extrernal and embedded;
4. [2] Javascript-defined styles will override everything.

This, then is the cascade in action: a web page is accessed and loaded. The external CSS is fetched and applied. The styling in the external CSS falls through to all elements specified in the CSS and those not already styled (this is inheritance) except where the HTML has defined it with embedded or inline tags, and any Javascript CSS definition cascades over all.

Staying In Versus Going Out

Given that inline and embedded styles are so powerful, the temptation would be to go wit them. There are probably times when that is appropriate. However, best practices (and the W3C consortium) recommend external CSS, for at least these reasons:

1. Ease of Revision: it’s far, far easier to revise styling in a series of HTML pages by editing just one external CSS file
2. HTML tidyness: moving CSS styling outside of your HTML file makes it smaller, neater, and more likely to play well with less standards-compliant browsers. Smaller HTML files are nicer to people with slower download speeds.
3. Inheritance: A few paragraphs up we referred to inheritance, the property that allows external CSS to style unstyled tags. Inline and embedded styles, despite their power, have no inheritance at all–they only apply to the tag they are used in. External CSS rules have full inheritance.

If none of these make the case for external CSS, one need only note that the standards world seems to be tending in that direction for at least a reason to do the same; standards-compliant HTML and CSS are what the current crop of browsers (and thier successors) are being designed to.

References:

• [3] Types of CSS Styles at About.com by Jennifer Kyrnin
• [4] Dynamic CSS Changes at Particletree.com by Ryan Campbell
• Teach Yourself CSS in 10 Minutes by Russ Weakley (Sam’s Publishing Teach Yourself Series, ISBN 0-672-32745-7)