Containment
vs.
The Cascade
I wrote this back at the end of May 2008 and didn’t publish it. When I thought about posting something similar a few days ago, I was surprised to find this nearly complete set of thoughts. I’ve decided to post this version, and will probably add some further thoughts on the topic soon.
For better or worse, Cascading Style Sheets are meant to cascade. That means if you style an <h1></h1>, all thing elements enclosed in <h1> tags well inherent that h1 style. This is both incredibly useful and incredibly troublesome.
It nice that if you really do want all your <h1>s to look the same. The cascade assures that they do regardless of the <div> they’re under or the classes you’ve given them. It’s a problem because when you absent-mindedly use an <h1> tag without remembering that you’ve styled the attribute, you can get some wonky looking stuff.
There are two basic means to deal with this reality: containment and a laissez-faire “let it cascade” approach. The first has the advantage of meaning that you never accidentally have things cascade, but the disadvantage that your stylesheet may well end up incredibly verbose. The latter has the advantage that when used correctly it can give you surprisingly brief stylesheets, but while composing that sheet you may well fall victim to the aforementioned surprise cascade.
Before we get too far into the analysis of the problem, some basic understanding. A containment strategy will wrap everything in every ancestor class all the way down to the exact element you’re styling. This assures that you never have a single style cascading in an expected way, and will generally yield something like this:
#container #content .post .entry p {
margin: 1em 0;
font-size: 1.2em;
font-face: "Times New Roman", Times, serif;
}Conversely, a cascaded style you only define what you’re styling in a loose and primarily pragmatic manner. The above might come out simply as:
.entry p {
font size: 1.2em;
}This obviously assumes that face and margins were defined elsewhere. And though it’s not always going to be true, it’s a realistic possibility with a full-fledged cascade.
From a simple length perspective, there’s reason to assume that the latter method is better. But you never know when you’ll realize that you’ve already styled <p> to include font-size: 5em; or some such nonsense. In this case — and this is a unique problem for those sizing thing in ems — you’ll get a font size of 6ems, or around 60 pixels, certainly not what you wanted.
I’ve got a gut-level aversion to verbosity where it’s not necessary. But I don’t like being surprised by unexpected cascading bits either.
There is, I think, a way to split the difference. A managed cascade can allow for a reasonable number of “presets” while still leaving sufficient room to avoid the accidental cascade. Though I still think that browsers welcome movement away from crude text resizing and toward zoom will eventually render the use of ems for sizing completely obsolete, that day isn’t here yet. (And if it were, not all the issues in the containment versus cascade battle would be resolved.)
So for now, I think it’s best to contain as much styling as you feel is reasonable, while allowing some things to cascade. It’s an unconscious working assumption I’m sure more than a few designers already use, but it’s a conscious one I’m certain I’ll be helped by.
