Even those of you in the audience who are new to web development (or perhaps just new to the site) have still probably heard the word “semantics” or the phrase “semantic development” thrown about in various web-related conversations (and if not, I certainly hope you will soon!). But what does that phrase really mean? Today, I want to take a brief step back from our normal how-to fare to talk about why we do things the way we do them: the semantics that guide our development.
A Definition of Semantic Development
So what does this whole “semantics” thing mean? In web development, we use the term to refer to using tags that describe what something is instead of what it looks like. Or to put it another way, as Dan Cederholm states in his fantastic book Web Standards Solutions:
[W]e’re striving to use tags that imply meaning, rather than a presentational instruction. Are you dealing with a list of items? Then mark it up as such. Is this a table of data? Then structure it that way.
So in short, when we’re talking about semantic development we’re looking for a way of separating our structural information from our presentational information. And luckily, we have all the tools we need right in front of us. CSS is a presentational language; stylesheets affect the appearance of objects, not their underlying structure. This means we can use XHTML to create our structure (and only our structure), and move all of our presentational stuff into our CSS.
Understanding Unsemantic Markup
Now that we have a definition in mind, let’s look over a few examples of what semantic markup is not. Once you get comfortable playing “spot the not,” the definition will start to make a lot more sense.
Here’s an example of how not to create a large heading for your blog posts:
<p><b>Semantics, Schemantics</b></p>
And here’s another:
<div class="headingBig">Why Konqueror Rocks</div>
Now admittedly, with the right CSS to back up your mad XHTML hackery, either one of these could end up looking like a perfectly legitimate heading on the screen. So what’s all the fuss about?
These examples are unsemantic for two reasons. Both of our examples are using tags (or classes) that don’t have anything to do with headings to create a heading-like effect. This is a faux pas because we have a tags at our disposal for the express purpose of creating headings: namely, the <h1> through <h6> tags. A good portion of writing semantic code is simply knowing the tools (tags) at your disposal and when to use them.
Of course, there isn’t a single tag for every use case, so sometimes we just have to do the best we can. And sometimes that causes debates within the community, because oftentimes complex problems can be solved with several different, arguably semantic, solutions — like when I argued that a calendar could be represented using an unordered list instead of a table (you can also see my follow-up article here).
Second, our first unsemantic heading example is using a presentational tag. In XHTML, at least, the <b> (bold) tag is generally frowned upon, precisely for the reason of semantics. The difference between a boldfaced word and a roman word is a presentational one — the bold tag doesn’t offer any semantic information about the text it wraps. That’s why XHTML offers the options of using the <strong> tag instead. The strong tag simply suggests that the word/phrase/whatever that it wraps is text that is somehow stronger than its surrounding text. The tag doesn’t dictate how that text should be strengthened… only that, semantically speaking, the text contained within is comparatively stronger. We can then turn to CSS to determine how our strong tag should be treated in our document.
Tips for Semantic Markup
So how can you help ensure that, moving forward, you’re generating logical, semantic markup instead of sloppy, structural-presentational code soup? Here are a few suggestions to help you along the way:
- Know your options. Unless you’re the guy (or gal (okay, probably guy)) that wrote the XHTML specifications, there are probably more XHTML tags out there than you know. This XHTML Cheat Sheet might be a nice place to start learning more.
- Think structurally. When you’re writing XHTML, try to boil things down to what they truly are, instead of worrying about what they’re going to look like when your site is done. Theoretically, a well-designed structure should be able to accommodate all sorts of different designs without having to change. That’s the idea behind the CSS Zen Garden, though admittedly their XHTML is pretty darn verbose to give the designers plenty of “hooks.”
- Code inside the box. XHTML is an amazingly flexible language, but sometimes its easier for me to code semantically if I treat my XHTML like I would a language that was going to be interpreted by machines instead of humans. Your computer doesn’t care what a heading looks like — it cares that it can classify certain data as headings. This has the added benefit of resulting in pages that machines (like Google’s bots) do understand… resulting in a nice SEO boost in the end.
If you have any more tips, things that you do to help yourself code more semantically, I’d love to hear about them in the comments. Drop me a line!