Posts Tagged ‘cascade’

Be Lazy, Let the Browser Do the Work for You

Friday, April 11th, 2008

Imagine you work for a company that has an online product catalog and that your job is to maintain the product images. Now imagine your boss comes to you and says, “here’s a list of a thousand products that need to have ’40% off’ put on them, and we need it for tomorrow, noon.” So you work all night only to have him come to you in the morning and say, “did I say forty? I meant fifty.” Now you’ve got till noon to update a thousand images, go! The more efficient way to handle that situation would be to have a macro, or a template, or some other automated way to either update those images or just superimpose the discount on each of those images.

The moral of the story is, work smarter not harder. When a computer can do the work for you, let it. There’s no glory in doing it yourself. This same moral can be transposed to front-end web development.

There is this thing called “flow” in the browser environment. Think of it as a really crude physics engine. All of the elements rendered in a page are initially a part of the document’s flow. When an image within the flow is enlarged, the text adjacent to it gets shoved over. When it’s reduced, the text is drawn closer. This is good because you don’t need to worry about positioning the text when playing with the size of an image. It’s handled automatically by the browser.

Now imagine if you were to break the flow and opt to position everything yourself. Maintenance would become a nightmare. Sadly this often happens when people get their hands on CSS and don’t know how to properly leverage it. Instead of letting the browser handle the positioning of the elements and just nudging them in place with a few strategically placed rules, they opt to brute force everything into position. Of course, what happens when an image size changes? or a bit of text goes longer than anticipated? Everything breaks. Then they’re up all night fixing a ton of style sheets.

The thing to remember with CSS is: less is more. Really, the cascade works best in conjunction with document flow. Restraining either too much defeats the purpose and leads inevitably to unnecessary headaches.

The C in CSS Stands for Cascade

Thursday, April 10th, 2008

People have a propensity to see a one-to-one relationship between an element and its look. In other words, they see an element as being styled much like if you were to paint something with a paint brush, a one-off job. At least that’s the way things were circa the early 1990′s with font tags and inline styling attributes such as bgcolor. This meant a lot of work to style a page, and once it was done, it was on to the next page and a whole lot more work. Of course work isn’t a bad thing, and nobody can fault you for working hard. But working needlessly? That’s another story.

In 1994 Håkon Wium Lie and Bert Bos collaborated on Cascading Style Sheets. The idea was that styles could inherit or cascade from one another. This marked a fundamental shift in the way an HTML document could be styled. It was now possible to affect the look of all of the elements of a certain type in a page and throughout a site with just one rule.

p {
    color: red;
}

This rule for example would colour the text in all paragraph elements red. If, however, you wanted one particular paragraph’s text to be coloured blue, you could assign it an ID and target it specifically.

p#intro {
    color: blue;
}

Here the text of the paragraph element with the ID intro will be coloured blue. Note however that all paragraphs are coloured red and only one is blue. The latter is originally red as well but is then overridden by a more specific rule and becomes blue. Hence the cascade. Taking advantage of this sort of broad stroke styling allows for very easy maintenance and updating of a site.

It’s therefore tragic when an old school one-to-one mentality is applied using CSS. Take for example this bit of code:

p#welcome {
    color: black;
    font-size: 115%;
}

p#about {
    color: black;
    font-size: 115%;
}

p#sale {
    color: red;
    font-size: 115%;
}

p#contact {
    color: black;
    font-size: 115%;
}

Here we have four style rules that do pretty much the same thing. The only difference is that the paragraph with the ID sale is coloured red. This CSS would be much more efficient if it took advantage of the cascade.

p {
    color: black;
    font-size: 115%;
}

p#sale {
    color: red;
}

Note how the sale paragraph doesn’t have a font-size rule. That’s because it inherits its font size from the basic rule that applies to all paragraphs. This makes maintenance much easier.

So remember: leverage the cascade, it will make life a lot easier for you when maintaining (and even debugging) a site.