CSSnewbie

On Calendars, Lists, Tables and Semantics

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.

An Argument Against Faux Absolute Positioning

A week or so ago, Netherlands-based Eric Sol published an article on A List Apart titled “Faux Absolute Positioning,” where he outlines a new system of element positioning that he has developed. Shortly afterwards, a reader wrote to me and asked my opinions on the technique. In the spirit of continuing the fantastic conversations we’ve been having on CSSnewbie recently, I thought I would respond publicly so that others might have the option of offering their opinions as well. But if you haven’t read Eric’s article yet, please do so before responding, so you have the full picture and not just my interpretation of things.

Mr. Sol’s development of the Faux Absolute Positioning technique was born of frustration in trying to use the two dominant positioning techniques: absolute positioning elements, and floating elements. His argument against using absolute positioning for page layout is that it causes any containing elements to collapse (because the element is pulled out of the document flow), which can cause all sorts of problems. This, I will entirely agree with.

However, his argument against using floated elements is that content changes can cause the width of the element to change, which can in turn wreak havoc on float-based layouts. This is partially true. Left to its own devices, for example, a 500 pixel wide column containing a 550 pixel wide image will probably ruin a float-based layout. However, in practice simply applying a rule of “overflow: hidden” to that column would have eliminated any column-resizing problems in nearly all cases, simply cutting off the side of the image when it reached the edge of the column. And considering that using Faux Absolute Positioning relies on an understanding that “the content of the boxes may overlap,” but that “it’s better to risk overlap than risk breaking the whole layout,” I don’t understand what makes using “overflow: hidden” on floated elements so detrimental or different.

But that isn’t my real concern with Eric’s argument for the technique. I’m most concerned with the XHTML structure required to actually implement the technique. As I’ve mentioned before, I’m a bit of a code purist. I believe in using the least amount of code to the greatest effect, and this is especially true when it comes to XHTML. A CSS file can be cached and reused by the browser over an entire website, reducing the strain on a user’s bandwidth. However, each new page a user visits requires them to download an entirely new XHTML page, regardless of how similar that page is to the previous one they visited. In my mind, this is the strongest argument behind switching from presentation-heavy HTML (tables, font tags, etc) to semantic XHTML (and using CSS for presentation) in the first place.

Because of that, I wince when I see the XHTML used to implement the Faux Absolute Positioning technique. Take a look at the sample offered:

<div id="canvas">
  <div class="line">
    <div class="item" id="item1">
      <div class="sap-content">content here</div>
    </div>
  </div>
</div>

Does that structure look strangely familiar? It should – it’s a table, converted into divs. The “canvas” div functions as the table container, while the “line” class of divs acts as rows and the “item” divs behave as table cells. In fact, this technique actually uses an additional div (“sap-content”) inside of each “cell,” bloating the code even further. Compare it to this table-based reimplementation:

<table id="canvas">
  <tr class="line">
    <td class="item" id="item1">
      <div class="sap-content">content here</div>
    </td>
  </tr>
</table>

Now, I understand that there is a semantics argument to be made here. Mr. Sol probably didn’t want to use a table because, semantically speaking, a table should contain tabular data and nothing more. But the problem is, the Faux Absolute Positioning technique simply reimagines tables using divs and classes rather than “tr” and “td” tags.

The real benefit of the technique, Eric states, is that “we can align every item to a predefined position on the grid […] but items still affect the normal flow,” and his insistence on thinking of elements in a page as “cells in [a] grid” is telling: the author really just wants to use a table, but can’t justify it semantically. Thus, he develops a “semantic” alternative that, instead of suffering from non-semantic code, suffers from divitis, classitis, and code bloat instead.

I wrote an article a couple of weeks back on building a calendar using lists instead of tables that ended up sparking a great deal of thoughtful debate of the nature of calendars, the semantic meaning of tables, and the overuse of lists in modern web design. I plan to respond to that debate more fully next week in a separate article, but one point I plan to make then is worth mentioning now: I believe in using semantic code wherever possible, but I also believe in minimizing code wherever possible. One of the (several) reasons I was so intrigued by the possibility of a list-based calendar is that I knew I could create it with less XHTML than a table-based calendar would require, reducing the bandwidth costs of whatever website it was implemented on.

The Faux Absolute Positioning technique, by contrast, requires at least as much XHTML as an equally complex table would require, and may actually require significantly more code because of the additional div inside each “cell.” Depending on the complexity of the site using this technique, we could be talking about 15% greater bandwidth costs on every single page of the website, compared to an identical site using a table for layout. Admittedly, the website could still tout a “table-less” design, at least in the narrowest definition of the phrase. But because of its insistence on rows, columns, and a clearly defined grid, it is at least a table in spirit, and may in fact be more complex and weighty than a table would be in practice. And if a designer is utterly committed to having the rows, columns, and cell-based grid that this technique permits, I would argue that the table tag deserves a second look, if for no other reason that to reduce page size.

At the end of the article, the author does admit that this technique is probably only sufficiently rewarding to be used on rather complex page layouts. But if a site’s layout has reached the level of complexity wherein the only viable options are to use a table to create a grid or reinvent a table to the same end, perhaps it’s the design of the site, and not the code behind the site, that should be reconsidered.

Now, I don’t want to be seen as attacking Mr. Sol’s person or work. I respect the amount of time it must have taken to develop the Faux Absolute Positioning technique and the ingenuity that went into the CSS. My goal here is to simply encourage a debate on the subject. And now that I’ve had my say, I would love to hear what you think about all this.