http://www.joedolson.com/articles/2006/10/describing-a-semantic-calendar/

after a couple of afternoons studying the problem, i’m on the same page of Joe Dolson: there’s no perfect design, both approaches have their pros, so list and tables should be used depending on the visual representation.

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.

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?