“I would like to get away from tables all together. Does anyone know of any
examples of markup for a tableless calendar?”
Where did this notion come from that if you are designing web pages using CSS that tables become some unmentionable evil to be avoided at all costs? There is a difference between the idea of “tableless layout” and “all tables are bad”. Tables are still a part of the HTML specs, and serve a very useful purpose. And, as others have already pointed out in the CSS-Discuss mailing list from which the above quote was taken, calendars are perfect candidates for tables.
Okay, actually I do know where that idea came from. You see, as modern web browers gained in user share, CSS became more and more of a viable option for web designers. And as more designers started realizing the advantages of separating “content” from “design”, they began to delve more deeply into the semantics of just what all those HTML tags are supposed to mean. The web is rife with discussions of <strong> vs. <b> and <em> vs. <i>. You see, <strong> and <em> have semantic meaning. They indicate that their content is important to the reader, whereas the <b> (bold) and <i> (italics) tags merely tell the browser to render text a certain way, without indicating why they are marked as such. A better example — if I have a bit of text marked up with the <i> tag, you have know way of knowing why I marked it that way. But if I use the <cite> tag, this adds meaning — the text is a citation. If I use the <kbd> tag, you can infer that this is something that you are supposed to type at your keyboard. If I use the <abbr> or <acronym> tags, you know that I’m using an abbreviation or an acronym.
Next, designers began to look at the issue of accessibility. This is where the table-less layout movement began. I don’t want to get into too much technical detail, so I’ll just point out that many people with visual impairments use special web browsers. Some are just text-based browsers, others use speech synthesis to read the content of a web page to the user. Some of these browsers don’t deal with tables well. Or they might try to deal with them well, but they can’t always know the intent of the web designer. For example, an audio browser will typically read the contents of a table from left to right, top to bottom. But what if a designer has used tables to lay out his content in a vertical fashion, so that you’re supposed to read content down one column, then up to the top of the next column? The screen reader will be reading the content out of order, causing some confusion. Again, savvy designers heed the call of “separation of content and presentation”, and the solution is to avoid tables.
Actually, that’s not true. The solution is to avoid tables for layout. Tables still have a purpose — they are used to markup content that is of a tabular nature. Calendars, for example. Or the periodic table of elements. Or your bank statement. There are countless good examples of when to use tables. And even using them for portions of your page layout isn’t totally evil, as long as you plan ahead and make an effort to keep your content organization logical.
If your web site is meant to be a visual attraction, then go hog-wild. Use whatever layout techniques get the job done! But if your site is about content — words, information, knowledge — then you should be thinking about how you can use semantic markup to add meaning. The chances are good that you will one day be glad that you did.