I recently read Peter Morville’s fantastic book, Ambient Findability, which defined really well the motivation to use semantic descriptions for links: they give the target page aboutness.

Simply defined, aboutness is the quality of meaning; what something is about is defined by its aboutness. To extend an example from Morville’s book, let’s regard a web page which contains W.H. Auden’s poem, Funeral Blues:

He was my North, my South, my East and West,
My working week and my Sunday rest,
My noon, my midnight, my talk, my song,
I thought that love would last forever; I was wrong

Although we know that the poem is about death, the word itself doesn’t appear in the poem; so how could a search engine that indexed the page know what it was about, and return it in the results of a search on that topic?

In order to gain some context, the search engine will look at the text of the links to that page*; so a link with the text ‘read more’ will provide no context whatsoever, whereas a link with the text ‘W.H. Auden’s poem about death’ provides aboutness.

And it’s not just for our link text that semantics are important; the same principle applies with HTML — your markup gives aboutness to your content. So if you’re a front-end coder, be sure to at least use appropriate container elements (the HTML5 Doctor can help with this), and if you want to go further take a look at the likes of Microformats and RDFa.

* Search engines look at more than this, of course, but this is the most obvious example.

One slight drawback of the technique is the blank space that’s displayed as the new font is loaded into the browser; this is especially unnecessary for users who already have that font natively on their system.

The way to get around that is quite simple; use local() to check if the font is on the user’s system first.

The syntax is:

@font-face {
font-family: 'Graublau Sans Web';
src:
    local('Graublau Web'),
    local('GraublauWeb-Regular'),
    url('GraublauWeb.otf');
}

You’ll notice there are two calls to local(); the first is for the full name, the second for the Postscript name; this is required for Safari in OS X.

The cascade is used so that only if the first two conditions aren’t met (that is, the font is not on the user’s system) will the third come into play, loading the font into the browser’s cache. This won’t get rid of the blank space, of course, but it will reduce the number of users who see it.

Here’s an example paragraph which will display in the excellent Graublau Sans Web family mentioned above — as long as you have a browser which supports the feature.

Don’t forget, you will need to declare the rule for each face (bold, italic, etc) in the font family. There’s a good introduction to the whole topic at Beautiful Fonts With @font-face.

The way around it is to quickly check that the command is supported by your browser, and to provide an alternative (I use that old standby, alert) if not; and the quickest way to do that is with the if…else shorthand:

window.console ? console.log(foo) : alert(foo);

That’s not the case, of course; with a few notable exceptions, the markup is completely customisable, and it is the order of the class names (and other attributes) which matters.

As a quick example, here’s what the hCard Creator outputs (minus the promotional sentence) when I enter my name and email address:

<div id="hcard-Peter-Gasston" class="vcard">
<span class="fn">Peter Gasston</span>
<a class="email" href="mailto:peter@broken-links.com">peter@broken-links.com</a>
</div>

This could just as easily (and correctly) be marked up like this:

<p id="hcard-Peter-Gasston" class="vcard">
<strong class="fn">
<a class="email" href="mailto:peter@broken-links.com">Peter Gasston</a>
</strong>
</p>

Or like this:

<ul id="hcard-Peter-Gasston" class="vcard">
<li><em class="fn">Peter Gasston</em>
 (<a class="email" href="mailto:peter@broken-links.com">email</a>)</li>
</ul>

All the examples conform to the hCard specification, but in each case the markup is customised to better resolve a particular coding requirement.

It’s really worth taking a look through the Microformats Wiki and spending a little time with the specifications in order to see the fundamental requirements of each, and to find out how much leeway you have in marking up your data.

What I do instead is much simpler; I use an extra stylesheet just for testing, and a single PNG image tiled across the background.

The PNG is in a reverse ‘L’ shape with a coloured area representing the gutter between columns, and the white area the column width. Here’s one I made earlier:

I call the tiled image from a stylesheet I usually call ‘testing.css’, which has just a handful of rules:

body {
background-image: url('grid.png');
margin: 0;
}

div { background-color: transparent; }

Obviously the exact rules are up to you, but the idea is to align the site over to the left, tile the grid image across the whole page, and make all the structural elements transparent so you can see the site overlaid onto the grid and make any necessary code changes. This image shows an example of this in action.

So as you add new elements to the site you can quickly drop a link to testing.css in with the rest of your stylesheets to test the alignment, then remove it (or comment it out) when you want to proceed with the rest of the build. This is a quick and easy way to get your site laid out to the optimal alignment to a grid without using a framework.

One of the things I see a few people struggle with when learning CSS is the concept of the cascade. I admit that as your stylesheets get more and more complicated, so the cascade gains in complexity with it. At it’s core, however, it’s pretty simple. There are three things you need to keep in mind: order, specificity, and inheritance.

Order

In a nutshell: if two declarations are applied to the same element, the values of the declaration which come later in the document flow (which I shall refer to as the ‘most recent’) are applied. Here’s an example:

h1 { color: red; }
h1 { color: blue; }

In this case, the h1 element will be colored blue, because that declaration is the most recent in the stylesheet.

Obviously this will be affected by whether a style is external (or embedded) or inline — inline styles always win because they are more recent than styles in the head. Also, this rule only applies when declarations have an equal specificity; see below for an explanation of this.

Specificity

Declarations can be weighted to change the order. This weighting depends on which selector (or chain of selectors) is used to apply rules to it. Andy Clarke put together a specificity table using Star Wars characters which explains the rules in detail, but at it’s most basic it’s this: id selectors overrule class selectors, which in turn overrule element selectors.

Say for example you have this markup:

<h1 class="title" id="page-title">

And these rules in your stylesheet:

h1 { color: red; }
#page-title { color: green; }
.title { color: blue; }

The colour of the h1 would be green, because even though the class selector is more recent, id selectors have a higher specificity.

Inheritance

You can probably guess this from the title; child elements inherit values from their parents (in most cases). Say for example I have my h1 element in the page again, and the following rule in my stylesheet:

body { color: red; }

My h1 element would display in red also, as it inherits the value from it’s parent — the body. As I mentioned before, that doesn’t happen in every case; links, for example, don’t inherit colours from their parent element. A little trial and error should let you know what is and isn’t inherited.

Summary

Although this has been a very quick run-through and can’t hope to show every facet of the cascade, I hope someone reading this gets some use out of it and it helps them fix some troublesome behaviour!

• CSS: Using the cascade
• Sitepoint CSS Reference: The Cascade