Code Standards | Isobar

Now we have something else to be thankful for. Nathan Smith of Sonspring has created a library that gives designers and developers “some measure of control over form elements, without changing them so drastically as to appear foreign in a user’s operating system.” Smith calls his new library Formalize CSS:

I’ve attempted to bridge the gap between various browsers and OS’s, taking the best ideas from each, and implementing what is possible across the board. For the most part, this means most textual form elements have a slight inset, and all buttons look consistent, including the button tag.

For more, including demos, options, screenshots, thanks, and the library itself, read Smith’s write-up at SonSpring | Formalize CSS. Hat tip and happy Thanksgiving to my good friend Aaron Gustafson for sharing this gem.

When you have a key-value list what HTML tags should you use? I’ve been thinking a lot about this and I’ll say it flat out: the answer is tables. Here are some of the common tags used to contain key-value pair lists and why using tables is better.

Tags That Don’t Work Very Well

Dictionary Lists

You could use a dictionary list like so:

<dl>
<dt>Color</dt>
<dd>Red</dd>
<dt>Shape</dt>
<dd>Square</dd>
</dl>

Semantically, this kind of works out. It has key and value tags, dt and dd. But the problem comes with formatting. What if you want to put a border around a key value pair? Well, you can’t. One solution is to wrap each key-value pair in its own dl tag, but that seems like a lot of work and then you lose out on the whole list wrapper, so you have to wrap the whole thing in a div or something depending on your formatting requirements.

This is not to say that dictionary lists are bad, they are perfect for things that closely resemble actual dictionary lists, but they are not a very good general key-value pair container because of limited formatting options.

Unordered Lists

Unordered lists are very flexible and can wisely be used for all kinds of lists. The other day I saw them used as a container for key-value pairs like this:

<ul>
<li>Color <span class="Value">Red</span></li>
<li>Shape <span class="Value">Square</span></li>
</ul>

In many cases this will work fine. It has the benefit over a dictionary list that both the key and value are contained within one element. It has the downside that the Value span has to be formatted to undo any formatting you’ve given the li (the key). This could be altered by adding a Key span, but at that point you may as well just use a bunch of divs. This doesn’t give you very good CSS free presentation and completely loses the semantics of the data. The point of HTML is that if there’s no style things still end up looking fairly decent and that at the very least, the HTML can accurately represent the data relationships.

The Winner

Tables

We’ve been so conditioned against tables and rightly so. People have abused tables in the past to format their pages to the point where you can’t tell what’s going on. But remember the rule, “Tables should be used for tabular data.” A list of key-value pairs is an excellent example of tabular data, but I think people don’t think to use tables at first because the tabular data in this case only has two columns. People start to think of tables for things with three or more columns. Here’s the markup.

<table>
<tr>
<th>Color</th>
<td>Red</td>
</tr>
<tr>
<th>Shape</th>
<td>Square</td>
</tr>
</table>

This fixes all the problems. Each key value pair is enclosed in a tr element. The key is enclosed in a th and the value is enclosed in a td. The default formatting is going to be perfect.

Furthermore, tables offer so much more extensibility. If you need a header row, break out the thead and tbody elements. If you need a summary row at the bottom, add another tbody element. It’s ultimately extendable with no classes.

Of course, that doesn’t mean it’s the solution for everything. If what you have is a dictionary list, then of course the dictionary list tags are going to work better. But for general key-value pairs, and the ways we generally think of formatting key-value pairs this is way better.

It might be time to get back in touch with tables if you’ve stopped thinking about them. Once you drop the idea of tables being used for page formatting and adopt the idea of using them just for small blocks of data you can really start to see how great they are.

The CSS for tables is a little more complex, so take some time to start understanding that. I’ll give you a hint, though. Do yourself a favor and use the border-collapse property. It takes a lot of the fuss and mess out of formatting tables:

table
{
border-collapse: collapse;
}

Difficult Situations

I just thought I should mention here that I have run into one situation that isn’t covered very well by any existing HTML elements and in its nature is just difficult. This is the case where you have individual key-value pairs that you want “arranged” in an some custom manner. For instance you want the key on top with a border on the bottom and the value beneath that. Then you want those elements to be lined up horizontally:

Color Shape
-------- --------
Red Square

Using more radical CSS dictionary lists can be made to perform this way although it’s probably better handled by turning the table suggestion above on its side and using a table with two rows, a header row and a data row depending on how you want it formatted.

<table>
<thead>
<tr>
<th>Color</th>
<th>Shape</th>
</tr>
</thead>
<tbody>
<tr>
<td>Red</td>
<td>Square</td>
</tr>
</tbody>
</table>

That’s more HTML than absolutely necessary, the thead and tbody can be left out, but it still feel like a lot of HTML for something semantically simple. But at this point it’s going to take either a lot of HTML (tables) or a lot of CSS (dictionary lists) to make this particular scenario work. If you want it to work without CSS, you really have no choice but tables.

The issue with this concept is that it doesn’t allow for very long values or very many key-value pairs horizontally and the whole scenario is only appropriate when you know in advance the range and quantity of values to expect.

In Issue No. 302 of A List Apart for people who make websites, Joe Clark explains what E-book designers can learn from 10 years of standards-based web design, and Daniel Mall tells designers what they can do besides bicker over formats.

Web Standards for E-books

by Joe Clark

E-books aren’t going to replace books. E-books are books, merely with a different form. More and more often, that form is ePub, a format powered by standard XHTML. As such, ePub can benefit from our nearly ten years’ experience building standards-compliant websites. That’s great news for publishers and standards-aware web designers. Great news for readers, too. Our favorite genius, Joe Clark, explains the simple why and how.

Flash and Standards: The Cold War of the Web

by Daniel Mall

You’ve probably heard that Apple recently released the iPad. The absence of Flash Player on the device seems to have awakened the HTML5 vs. Flash debate. Apparently, it’s the final nail in the coffin for Flash. Either that, or the HTML5 community is overhyping its still nascent markup language update. The arguments run wide, strong, and legitimate on both sides. Yet both sides might also be wrong. Designer/developer Dan Mall is equally adept at web standards and Flash; what matters, he says, isn’t technology, but people.

Illustration by Kevin Cornell for A List Apart.

Dan Benjamin and yours truly discuss the secret history of blogging, transitioning from freelance to agency, the story behind the web standards movement, the launch of A Book Apart and its first title, HTML5 For Web Designers by Jeremy Keith, the trajectory of content management systems, managing the growth of a design business, and more in the inaugural episode of the Pipeline.