While they say a picture is worth a thousand words, not every image is self-explanatory. Sometimes a few words of description or context can make the difference between a confusing image and a clarifying one. That’s why image captions are often a good idea.
I’ve always liked the idea of giving images captions, but I rarely do. And why not? It seems to me that most image caption solutions out there:
Require a lot of excess HTML,
Make it difficult to redesign (because of the rigidity, usually),
Don’t make the relationship between image and caption clear, or
All of the above.
Today, I propose a solution that addresses many — if not all — of these concerns. Read On…
So today’s tutorial is all about going back to basics. This is what you need to know to build a simple navigation bar like the one pictured above (and you can see a working example here).
As with most modern navigation bars, ours will be based on the unordered list (<ul>) tag. This makes semantic sense, a navigation bar is really nothing but a list of links leading into your site. The traditional horizontal orientation is simply a convenient means to get all of our most important list items “above the fold,” so the user can see them without having to scroll down the page. Read On…
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:
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.
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:
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!
A couple of weeks ago, I wrote an article on creating a calendar using lists instead of tables. I was expecting a few people to find the concept interesting, and I was hoping for a little feedback from the web community. What I wasn’t expecting was the outpouring of comments and a very serious, fascinating debate on the semantic nature of calendars, the place of lists in web design, and more. And because I don’t think it’d be productive to just go through the list and respond to each comment individually, I thought I’d take some time and respond in a follow-up article. If you haven’t read the comments yet, I’d encourage you to do so first.
The first thing that I realized as the comments started to roll in was that my tutorial was fundamentally incomplete in a couple of vital ways. While I feel I did a decent job describing how to implement the technique, I fell short when it came to explaining how I envisioned the technique being used, or my reasoning behind what made using a list in lieu of a table such a useful idea. In other words, I’d covered the “how,” but not the “what” or the “why.” So I’ll cover more of that here.
I first came up with the idea for a list-based calendar at my 8-5 job as I was leafing through my appointments in Outlook. I thought about how useful it was to be able to switch between the month view, to the 7-day, to the 5-day, and so on as necessity dictated. I wasn’t restricted to just one view of my time: I had flexibility. And then I realized that even my day planner, an old fashioned, low tech paper product broke my time into months at the top of the page, but showed the days of my week in a more linear fashion.
And that got me thinking: was there any way to support that sort of flexibility in web-based calendars? I’d dealt with web calendars before: they were exclusively table-based and, as a result, fundamentally rigid. But what if, instead of turning to a table, I used a list? Then the data could be displayed linearly, like the 7-day calendar view of my planner, or in a grid like a traditional month-based calendar, as need dictated.
I was also thinking of my multiple-calendar setup in Outlook. I have two calendars: one for my meetings and appointments, which is generally useful in a month or week view, and one for my bills (I’m bad about remembering them!), which was really more useful as a list of dates. That convinced me even further that maybe a calendar didn’t need to be based on a grid.
And that explains my thinking on the “what” and “why” portions of the tutorial. I was looking for a flexible calendar solution, one that wasn’t locked to the month-based grid.
Because — to get more into the semantics side of things — I would disagree with those that commented that a calendar was, fundamentally and semantically, a grid-based (and therefore table-based) entity. If calendars are married to the grid, why does my Outlook calendar have so many alternative views? Why does my day planner make so much sense to me at a glance, even though the days are arranged in a single column? Thinking of a calendar as exclusively month-based and grid-based is a narrow way at looking at the concept, considering all the alternative options we as a culture use on a daily basis.
And all that plays into the semantics of the calendar. Is a calendar, semantically, a grid? Sure, if you’re talking specifically of a month-based calendar. But I’d argue that my day planner is much more closely semantically related to an ordered list, and my Outlook calendar is like both, depending on what view I’m using at any given moment.
I can understand now why my calendar tutorial stirred up such a big semantics debate: my tutorial showed a calendar locked in a month-based, grid-like format. I didn’t mention any of my ideas on flexibility, multiple views, or the rest. And that resulted in well-reasoned retorts in the comments and even elsewhere: for example, Unintentionally Blank argued that I had presented a grid, but used a linear tool to do so, and thus wasn’t using the right tool for the job. Similarly, commenter Mark Aplet directed me to a recent post on his blog visual28, where he argued that designers were using lists for everything; that, essentially, lists were becoming what tables had once been in the web design world.
And the ironic part of it all is, I agree with both of those stances. Yes, I worry that designers overuse lists: I am opposed to the idea, for example, of using an unordered list as a basic structure for an entire website. And I would also agree that, if you’re presenting tabular data, there’s no better tool than a table to accomplish that aim. Which meant that my earlier attempts to respond to the debate raging in the comments all started with, “Yes, but…” Which is how this, longer and hopefully more clearly argued article came about.
So, what say you, semantically impassioned readers? If the goal is to create multiple calendar views with a single XHTML file, is a list an acceptable tool or am I still trying too hard to live off the grid? Does a calendar by any other orientation smell just as sweet? Let’s keep the debate alive: we’ll all end up coming away a little bit wiser.
If CSS properties attended high school, you would never expect to see the border property sitting at the cool kids' table. Actually, you'd be surprised at just how cool the border property can be. Please take the following dozen exhibits as proof that the CSS border property is a lot cooler than we give it credit for. Read more →
After I wrote and published my last article on writing a function to equalize heights in jQuery, I realized that the function would probably make a really useful jQuery plugin. This is that plugin. This plugin is slightly more sophisticated than the function I wrote earlier this week. Read more →