Many times, when a developer first begins to use proper HTML and CSS for markup and style, he or she has a tendency to disown tables and avoid their use at all cost. While thinking that way can allow a developer to discover many creative ways of using the newfound power of CSS, it can put someone at a severe disadvantage.
Is this Data Tabular or Not?
The next step for that up and coming developer is to begin to think about the content that is being marked up, and decide upon the most semantic solution. If data is tabular in nature, mark it up as such, don’t be afraid. Tables aren’t evil, it isn’t their fault they were abused for so many years. When I was first starting out with CSS I was ecstatic about its abilities and wanted to use it whenever possible. I came up with some really off the wall solutions for simple problems, and I’m sure other developers can say the same thing.
I Say Calendars are Tabular
The fact of the matter is — there’s still data that is tabular in nature and should be marked up as such. One example I’d like to talk about is a monthly calendar. When I was first asked to create a calendar after learning CSS, the first thing I thought to use was an ordered list. I was in an ‘anti-table’ mindset and I spent the next few hours coming up with a pretty nice looking calendar that was based on an ordered list. The only trouble was the semantics.
Things seemed to make sense at the time; a calendar was really just a list of the days in a particular month ordered from first to last, how is that tabular? What I didn’t take into account was the extra set of list items I had to include in order to provide the weekdays at the top. I also didn’t think about what the calendar would look like to someone browsing the site in a text based browser. I was a CSS fanatic and never wanted to see tables again.
Why is a Calendar Tabular?
In my opinion, a calendar should definitely be considered tabular data. Dates are placed in a particular position on a grid based on which weekday they fall upon. There is only one day per position on the grid, and they don’t overlap. The month and weekday names can be included in a table heading because that’s what they are — headings. They give meaning to the data included below in providing an explanation as to which weekday a particular date falls.
A Few Accessibility Notes
A tabular calendar will also render more nicely on a text based browser as opposed to a list. When viewing a list based calendar in a text only browser, you’re given a top down listing of each day followed by any content associated with that day. That’s fine, but you’re losing the convenience of knowing the associated weekday (which is now at the top of the list by itself). Viewing a tabular calendar in a text only browser should be quite similar to using a modern browser which supports CSS. You still have your table headings which make the data easier to understand, and the information is organized in a way you’d expect to see it.
Being that I don’t have exclusive access to a screen reader, I’m not positive as to what a tabular calendar would sound like to someone who is visually impaired. Using Fangs we can get an excellent insight, however. First you’re given information regarding the table itself; summary, number of rows, number of columns, and the table headings. You’re then guided day by day through the table. Unfortunately, we lose the advantage of knowing which weekday a particular date falls.
What I’m Trying to Say
All in all, I think that the attributes of a calendar match well with what a table has to offer. In my opinion, a calendar is semantically a table and should be marked up as such. The code behind a list based calendar is ineffective at best highly based upon the fact that an extra set of list items must be included in order to provide weekdays. An argument to that may be that you don’t want to include the weekdays in this particular calendar because you’re only including a very tiny instance in your sidebar. Personally, I don’t think that’s a very good excuse. If you don’t want the weekday headings to appear, set your thead to display:none;. Always keep semantics in mind, it will be a great help in the long run.
Comments
This is a common misconception of tables now. And that’s unfortunate. But for a calendar, I’d say it depends!
If you have the headings, Mon, Tue, Wed etc then it’s most definitely a table. The days are th, which are in the thead. You can also add scope and header attributes too, associating days with the numbers..
If there aren’t any headers, then I say a list is just as appropriate. As it’s a list of numbers, which represent days. You mention hiding the headers, however, and this may be the better solution.
I agree about a calender being tabular data, and I certainly recognize the anti-table attitude 🙂
@trovster: Thanks for mentioning the ability to add scope and header attributes — I neglected to include that in the article. Regarding using a list if the calendar is only displaying numbers — I’m still not sure. Remove the style and you’ve got a list of numbers, right? When the data is marked up as a table, the nature of the data is still available and the day of the week can be inferred at least. What do you think?
I see this on CSS/XHTML forums all the time. A user will have a legitimate question about styling a perfectly legitimate table, and he’ll get blasted for using a table.
“You really shouldn’t use tables.”
This just reemphasizes the point that the web design/development industry is saturated with amateurs–they don’t know CSS/HTML, they haven’t bought any books on the subjects, and they misconstrue the preachings of standardistas.
A few key terms that trigger the use of a table in XHTML include, “chart, calendar, graph, spreadsheet,” etc.
Also, in addition to scope attributes, the Month and Year can be included in the CAPTION element, and weekends and weekdays can be grouped in specific COLGROUPs.
@Colin: Some really good tips in that comment, thanks! Regarding the saturation of amateurs in the field — I couldn’t agree more. At the same time, that’s one of the great things about the industry — there are always new people, it only becomes unfortunate when they refuse to learn.
[…] first article in this series, had I thought of it at the time, would have to be my questioning of calendar semantics, an article in which I ask which is more appropriate for marking up a calendar: a table or a list? […]
This is not a case for a table. If the table is static, this would work fine, but what about animating and enhancing the calendar with js? Now you have cut yourself off at the ankles as to what you can do. The real question you should ask yourself before you make these kinds of statements are…
What is the goal of the calendar?
How do I expect my users to interact with it?
Just my thoughts, from a js perspective, things become much trickier and even impossible when using a table.
PS. A list is a poor choice as well, but what about div’s….
@Kevin: Markup shouldn’t really have much of an effect on any JavaScript you plan on applying. JavaScript should be used to progressively enhance a document. It should be considered after the semantics of the markup. Using a months worth of
divsdoes not have much meaning behind it. If you were to take away the CSS, you’re left with data which turns out to be pretty meaningless.[…] why it can be looked at as misuse. I was glad to see that Mike and I share an opinion surrounding effective calendar markup. I’d like to suggest that you take a few minutes to read Mike’s piece and check out the […]
[…] вопрос и сформулировал запрос для Google — calendar table or list. Первая же ссылка привлекла меня и подтвердила мои соображения […]