Labelling it for what it is
March 25, 2002
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
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
id names to something semantic. So many of those layout
templates label the regions of the page like this:
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.
Coming Soon from CodeBitch
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,
id="left">, a list of recent posting on the right,
<div id="right">, and finally the main
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,
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
Often, you won’t need a specific class at all; a contextual selector
#callout a:link will work fine, and save filesize
compared with a set of links all with a
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
class="text">. I’d be equally disappointed to
<span class="booktitle"> –
<cite> is for.
There is no inheritance tax
Too many designers seem to think that using CSS means that everything goes inside
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.
SPANs are generic elements, and you
don’t need to wrap every piece of content in one or the other.
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.
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
Label your content for what it is, not where it currently goes.