Labelling it for what it is

March 25, 2002

Web designers all over are learning new ways of doing things. They’re separating style from content, as best as possible. They’re laying out things using CSS and DIV elements. They’re hiding styles from buggy browsers. What not all of them are doing is thinking structurally.

“Use stylesheets to format structural markup.” An important principle, but lately the first part has received more attention than the second. The pain of buggy CSS implementations, and the sudden realisation that there are nooks and crannies of CSS2 that we don’t really understand yet, have focused many Web authors“ attention on the CSS part of the Web design equation. There has been an explosion of interest in CSS this year, judging by the subscription rate to the CSS-d discussion list and the content of other mailing lists and Web sites. I’ve been glad to help many MacEdition readers move towards CSS-oriented Web authoring, through my columns and (on the rare occasions when I have time) by email.

Adoption of CSS-savvy browsers has got to the point that many designers feel comfortable about using CSS for much of their formatting. There are now some concerted efforts to generate templates using CSS for common Web page layouts. This is a welcome development, but I recommend that Web authors using these templates consider renaming their class and id names to something semantic. So many of those layout templates label the regions of the page like this: <div id="left">, <div id="middle"> and <div id="right">. This makes perfect sense in a template, so that potential users can read it and see how it fits together. But it’s not appropriate for a production site.

Think about it: suppose you have a site with a header that you put in <div id="top">, a sidebar on the left with navigation to other parts of the site, <div id="left">, a list of recent posting on the right, <div id="right">, and finally the main content, in <div id="middle">.

Then next month, you decide that the recent postings look better on the left and the links to other parts of the site work better on the right. So you change around the positioning information for those two DIVs in your stylesheet. Oh, great – now <div id="left"> is on the right, <div id="right"> is on the left and you feel like a complete goose. You might get a promotion for improving the efficiency of the Web site, but your successors will probably also conclude you are a goose, and tell all their friends.

So use those templates from one of the template collections, but for goodness’ sake change the class and id names before you go any further. Call them “header”, “recent”, and “nav” or whatever fits your needs. Give them names that make sense and will survive a redesign.

Just enough class

The same goes for class names for different types of text. Don’t label them “smallgreyarial” or, as I saw on the Apple site recently, “G10” for 10-point Geneva. Call it what it is: legal, copyright, callout, whatever. You don’t have to spell out the type of content in too much detail (class="eruditecommentsbycolumnistaboutmarkup"). Often, you won’t need a specific class at all; a contextual selector like #callout a:link will work fine, and save filesize compared with a set of links all with a class="inthecallout" attribute.

Moreover, don’t set up a class when there is an existing HTML element that does exactly the same job. I’m sick of seeing <P class="heading"> and <span class="text">. I’d be equally disappointed to see <span class="booktitle"> – that’s what <cite> is for.

There is no inheritance tax

Too many designers seem to think that using CSS means that everything goes inside DIVs and SPANs, with no headings or paragraphs or list elements. These same authors seem to think that everything needs a class attribute, instead of using inheritance mechanisms. This style of authoring seems to have been encouraged by certain graphical Web authoring tools, and more than one crappy book on so-called Dynamic HTML. It’s not efficient, it’s not structural and it doesn’t leverage any of the advantages of a standards-based approach to Web authoring.

DIVs and SPANs are generic elements, and you don’t need to wrap every piece of content in one or the other. Nesting DIVs is more efficient than nesting tables, because of the way browsers render these elements, and because it’s one DIV, not a TABLE, and a TR and a TD. Still, you shouldn’t need to nest DIVs as much – margins, borders and padding on DIVs often supplant the nested tables of yesterday. You can use a single DIV with these styles, instead of one single-celled table for the margins, one to simulate a border, one for the padding because you were too ignorant to use the cellpadding attribute, and then finally one for the actual content.

Similarly, if every element in your document has a class attribute, you are doing something strange. Either use more structural elements in your markup, or more contextual selectors in your stylesheet. Fear of inheritance problems in Netscape 4 are understandable, but don’t just spray class attributes to get around it – test to see if it really is broken in the specific context of your design. You may be pleasantly surprised.

These aren’t silly rules and they won’t get in the way of your creativity. They are sound principles to make your site work better for non-standard devices, text browsers and search engines. Even if you don’t care about accessibilityfor the disabled (for callous reasons I can only speculate about), you should definitely care about how search engines cope with your site.

To summarise, effective authoring means using stylesheets to format structural markup, but not only that. DIVs and SPANs are grouping containers, not substitutes for paragraphs, headings, and other structural elements. Nesting multiple DIVs is only marginally better than nesting tables. You can have too much class.

Label your content for what it is, not where it currently goes.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend