Posts Tagged ‘style’

The Skinning Trade-off

Thursday, April 24th, 2008

Anyone who’s built a website has likely had to deal with the temptation to skin native browser elements, such as the pulldown menu, the input field, the radio button, the checkbox, the button, the text field and the scroll bar. The most common skinning job that pervades the web is that of the simple button. That’s because of the styling latitude browsers allow for that particular element. However, apart from a few colour changes, styling a pulldown, or worse a scroll bar, is next to impossible.

Even though browsers don’t allow elements to be skinned, it’s still possible to emulate them in JavaScript and skin them that way. But there’s a problem with this. Whenever you emulate a browser’s native functionality, you inevitably lose something. That’s because native elements have a whole slew of unseen things built into them that come for free. Some examples of this include focus and blur events, the ability to tab to them, that pressing the enter key while focused will in most cases trigger the element’s onclick event, and that changes to the state of some elements will be directly communicated to the OS for use by assistive technologies. Emulating these things is at best a difficult and cumbersome task and at worst, impossible.

On top of it all, usability experts recommend leaving these elements in their native rendering because that’s what users are used to and are expecting. Changing the appearance of an otherwise familiar element can cause confusion and will most likely cause users to think, which isn’t a good idea.

So even though skinning a browser element gets you all sorts of graphical awesome, you’re going to inevitably lose something by doing it. So the next time you’re tempted to skin a browser element, think twice and maybe just leave it alone, for all our sakes.

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.