caption-detail/tables and borderline semantics

tables, forms and presenting data

Remember all the discussions about forms, and how they could be interpreted as tables, semantically speaking? People tried to sell this idea on the basis that a form is nothing more than a table with one vertical header row (the field labels) and one vertical input row (the input fields). It's hard to contradict this, unless you think back of what I called borderline semantics. This is a prime case to apply such kind of reasoning. Just a quick reminder:

In a form you have one input field per label, and even if you have more (for example, if you're using three input fields for a date) they are not meant as a repetition of data. This already shows us that a table really isn't the best way to mark up a form, as a form will never have multiple rows, eliminating the possibility of "tabular data" in a form (unless of course you want one of those real table-forms, where you want the user to enter five times the same data for another entity). A similar reasoning can be made for presenting data (rows with labels and the actual data).

caption-detail

So if we can't use a table for such structures, then what should we use instead? The answer is the caption-detail structure. If you check the piece of code above you'll see an example of how such structure is composed. It does mimic a table, with the row class taking the function of tr element and both caption and detail classes mimicking td elements. That said, each row will only contain one caption and one detail element. The row class might seem useless in some situations, though it has a clear structural function and often comes in handy when cssing a caption/detail component.

In case of a form, the label goes into the caption element, while the input element goes inside the detail element. Added benefit is that this code is mostly reusable for showing the inputted data, so it increases the consistency of your code. The only thing which changes is the input element, which becomes the actual data.

base html code

There are various ways to implement the caption-detail structure. You could argue that the rows should be li elements in an unordered list. You could also use a definition list (though I wouldn't recommend it, if only because it's a terribly structured element). And you could always leave the rows out if you like minimal html. This discussion is beyond the scope of this article, but suggestions are always welcome. So far, I've always been using divs myself.

There's also a question of using spans instead of divs (for the caption and detail elements). This is pretty much dependent on the way the data itself is entered. I believe that when the caption contains a ':' or other textual separator the span element can be used (as it works like inline data). If no textual separator is present, it's probably best to use the div element to clearly separate both elements and to avoid confusion.

Finally, we can leave the "detail" div out too if you want to write really minimal html. It is then implied that the data without extra structural wrapper is the detail part of the structure. It's up to you, just not my cup of tea.

so is it useful?

Most projects I've worked on contained one or more caption-detail components. So it's good to standardize this piece of code. You can wrap the rows to add extra context to the component, it's pretty flexible to css and even though the base html elements aren't too flexible, the class names give a pretty good idea of the semantics of the element. So next time you run into a similar component, consider the caption-detail.