On Calendars, Lists, Tables and Semantics

Published July 2, 2008 by CSS Newbies.

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.

I created my first test calendar with that flexibility in mind. I envisioned it being used in a scenario where it was sometimes useful to see things in relation to their days of the week or place in the month, and other scenarios where it was simply more useful to have things broken down by date. I figured it’d be an easy thing to set up bit of PHP or JavaScript to swap between two CSS files, changing the view on the fly. Of course, when it came to the tutorial, I focused exclusively on how to implement the idea, and neglected to mention why such an idea might be useful.

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.

9 Responses

  1. Pingback: A Semantic List-Based CSS Calendar - CSSnewbie

  2. Phil Nash (reply)

    Rob, I’m glad you decided to follow this up with a deeper explanation.

    You are right, calendars can be formatted as a list, in Outlook or physical calendars, so why not on the web?

    I still argue, however, that bending a list into a grid such that at a click of a button it could become a list again isn’t the correct way of going about things here. I’m not saying that markup should be used to dictate presentation, but the semantics of a list based calendar and table based calendar lend themselves to each visual format as well. The column headers for days of the week in the table version and the ordered list numbering of the days in the list version both mean something extra in that format and help them to be understood.

    If you want to swap between table and list view, why not have an implementation of both and hit a link to visit the other type. If you want it more dynamic, a bit of AJAX to swap out the implementations. While this sounds like more work, having looked through some of the struggles and quirks of pulling a list into a grid, I think it’s a more worthwhile and robust use of time.

    I hope this all makes sense, it’s early and I haven’t reached for the coffee yet. What do you think?

  3. Pingback: Webmaster Libre | ¿Se han convertido las listas en las nuevas tablas?

  4. Pingback: Nono Martínez » ¿Se han convertido las listas en las nuevas tablas?

  5. Rob (reply)

    I think of my calendar data as a group of data records in a database. I can get a report of a subset of this data using whatever criteria I wish and sort it in any order that is useful to me. Then, and only then, does it make sense to decide how to display that data.

    It seems like some people, the ones who focus on displaying data, confuse the map with the territory. They get locked into displaying the data and loose sight of the total picture.

    I’m a programmer by training, not a designer, so I’m often struggling to find an artful, yet flexible way to display the data in the dynamic systems I design.

    I find CSS to be an impediment to design flexibility. Never the less I must live with the tools and systems in the real world now, not five years from now. If I want to use CSS I am forced to generate it dynamically to overcome it’s lack of variables.

    I guess this is a long way to go in saying that I don’t really care if I have to generate XHTML for tables or lists to get the job done. But I do want to generate one set of code that runs on all important browsers.

    So, while the calendar build with list elements is easier to generate, why does anybody care what’s under the surface as long as it works? If your list method worked in all important browsers, I’d use it. But, as you said in your article, it doesn’t.

  6. Pingback: Codigos Web » Blog Archive » ¿Se han convertido las listas en las nuevas tablas?

  7. Pingback: Understanding XHTML Semantics

  8. Marcus Tucker (reply)

    There are 365 days in a year, 7 days in a week, and 24 hours in a day.

    A month-to-a-page calendar is merely one of many possible views of this sequence of days and hours, a 7days-to-a-page view is another possibility, as is a daily schedule divided into hours.

    To me, the days of the year are a sequential list, and the hours within them are a nested sublist within each day, so it makes perfect semantic sense to represent them as list items in the context of (X)HTML and to use CSS / JS / etc to present them in (or transform them into) whatever form is appropriate for the task at hand. And to go one stage further back, the day & time information could also be stored / retrieved as XML or RSS in the backend, then transformed into OL/LI list elements prior to presentation.

    One could also use the underlying list structure to create a way of dynamically switching between any of the three views that I mentioned above without incurring a server roundtrip, simply by changing the presentation logic rendering the underlying list data.

    If I ever get the time I might experiment with creating a view-shifting calendar, perhaps even using something like Quicksand (http://razorjack.net/quicksand/) to enhance the user experience.

    In contrast, all of the above would be significantly more complex to achieve using tables & cells, and far less semantically meaningful either.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>