The Tabular Data Enigma

Did you know that tabular data doesn’t really exist? Yes it’s true! Recently at work, I was discussing the advantages of semantic markup with a colleague and stumbled upon an interesting conundrum. In the conversation, we agreed that table based design layouts are bad, and that tables should be used for tabular data. I think you’ve probably heard the same elsewhere and would probably agree as well. The sticky point however was that my colleague then proceeded to state that the application he was working on, which used <table> tags to markup the output, was semantically correct because it was a file browser of sorts which was ‘tabular data’. I proceeded to point out it would be more correct to use the proper list tags (ordered <ol> or unordered <ul>) as it was a list of files. Frustrated with my response, he asked: “then what is tabular data?” and suddenly I found myself without a clear and concise answer.

The Term

It seems I had begun to play “follow the leader” without really thinking about what it meant. In the “table layout versus semantic layout” debate there are pros for the table and pros for semantics. The semantics side always cries foul when tables are used for positioning and layout, and they generalize their use in “Tables are for tabular data”. And I fully agree that stylistic layout is an obvious bad extreme for the use of tables in your markup. Layout and positioning on a page is not tabular in any way so tables are just wrong. At the same time, my raw apache log file displayed on a page would be an obvious candidate for mark up using a table. But what about everything else in the middle? Is a ‘list’ of files considered tabular data? and if not why? I honestly didn’t have a good answer so I turned to my good friend the internet and the blogoshpere for answers.

Googling for tabular data turned up few useful results. Many were map related (not sure why) and they defined tabular data as:

Tabular data consists of attribute tables that define the parameters of the map features. There is really no limit to what the tables can contain, whether Boolean strings (True/False), Text, or Numeric data. …The advantage of the relational database system is that the different columns can be sorted and selected according to the user’s need. Source

Ok, kind of useful, but it states there’s “no limit”. Another search for tabular information didn’t provide anything better. I figured in the realm of semantics there must be some sort of definition or guiding rule. Some magical statement that will tell me what I should be marking up in tables. But what could it be? Prodding a little deeper I came across the Tables html401 specification which states:

The HTML table model allows authors to arrange data – text, preformatted text, images, links, forms, form fields, other tables, etc. – into rows and columns of cells.

and

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

and it then proceeds to explain the specification for the <table> tags. Again, not very useful for my purpose as it states forms, links, images and the like can be in tables, but that’s like saying I should put some sort of liquid in my cup. I want to know what the liquid should be and if it’s appropriate for breakfast (orange juice anyone)?

Lastly I stumbled across an awesome reference on 456 Berea St. entitled “Bring on the tables”. As usual it states:

Something that often seems to confuse people that are new to CSS-based layouts is the use of tables. I’ve seen plenty of cases where people interpret “avoid using tables for layout” as “don’t use tables at all”. It’s important to remember that tables are still perfectly fine to use – if used correctly.

and does a wonderful job of explaining proper semantic table markup techniques (I highly suggest yo give it a read), but it fails to state what you’re supposed to put in the table. What is this mysterious tabular data?

A Definintion

So where does that leave us? Well from the various links and opinions we can form a general idea of what characteristics define tabular data:

  • a collection of records (rows) , each with common properties (columns),
  • a presentation of information in a grid format where a row represents one group of properties and a column represents a common property among all the groups (or arguably the revers),
  • provides a comparison of one group to another.

So from these vague characteristics, I conclude that there is no such thing as ‘tabular data’, and the phrase “Tables are for tabular data” is plain wrong. “Tabular data” as a noun doesn’t exist. It’s not a thing. It’s not something that I can point at and say “that’s tabular data, use a table to mark it up!” Tabular data, as the term implies, is data already in a table format. That’s why it’s called tabular data! So really the definition of tabular data is:

Tabular Data/Information
A collection of records (rows) , each with common properties (columns), presented in a grid format where a row represents one group of properties and a column represents a common property among all the groups, in order to facilitate comparison between the columns of each row.

The key thing to note is that by definition it requires two things: - a presentation in a grid format and - the need compare records against one another

When you’re talking about ‘Tabular data’ you’re really referring to a presentation format for any data where you want to compare items. As an example take a group of images marked up as a list:

<h1>My images (list)</h1>
<ul>
	<li><a href="a.gif">A</a></li>
	<li><a href="b.gif">B</a></li>
	<li><a href="c.gif">C</a></li>
</ul>

and then as a table:

<h1>My images (table)</h1>
<table>
	<thead>
		<tr>
			<th>Image File</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td><a href="a.gif">A</a></td>
		</tr>
		<tr>
			<td><a href="b.gif">B</a></td>
		</tr>
		<tr>
			<td><a href="c.gif">C</a></td>
		</tr>
	</tbody>
</table>

Which is more semantically correct? The list or the table? Before writing this post, I would have argued that an unordered or ordered list is the correct markup for a ‘list’ such as this, regardless of the situation, but now I’m not so sure.

My example consists of a group of links to images, as implied by the header. In the case of the unordered list, it offers no additional information about the relationship of the items in the list. Are they all they all the same? Are they related somehow? These questions can’t be answered beyond “They’re related in the fact that they’re in the same list.” In the case of the table markup, we have a better idea of what’s going on. We know that semantically, all the elements in the first column are image files as implied by the header of the column. We can also assume that, because it a table, each row is somehow similar to its siblings (they’re all links to files in this case). Additionally I could have added more semantic tags as explained in the 456 Berea St. article “Bring on the tables” that I mentioned earlier, but the tags I’ve used here is enough to get the point across.

So what about the visual appearance of this information? Using CSS can we make the two look identical from a stylistic point of view? Sure! To make them look like a typical unordered list you could do:

table, thead, tbody, tr, th, td, ul, li {
	border: 0; margin: 0; padding: 0;
}
tabe { border-collapse:collapse; }
table, tbody, tr, td { display: block; }
thead { display: none; }

a {
	padding-left: 20px;
	background:  transparent url(bullet.gif) no-repeat left center;	
}

which would produce:

or you could make them each look more like a table using:

table, thead, tbody, tr, th, td, ul, li {
	border: 0; margin: 0; padding: 0;
}
tabe { border-collapse:collapse; }
table, tbody, tr, td { display: block; }
thead { display: none; }

table, ul {
	width: 200px;
}

tr, li {
	margin:  4px 0;
}

a {
	display: block;
	padding: 5px;
	background: #efefef;
}

which would produce:

Either markup will produce identical stylistic results with the right combination of CSS, tags and selectors, so in this particular case I would now argue that a table is a valid option if the semantic intention of the information is to compare the items. An ordered or unordered list is still the correct choice if the intention is to simply offer a list various items or options, especially if the items are unrelated or represent different things that can’t be directly compared. Navigation, for example, should still be a list. The goal of a navigation bar is not to compare the properties of each navigation button to each other, it’s to list the available options. Likewise, table are still unrealistic for layout and positioning since in that case, the table serves no semantic purpose whatsoever.

{.caution}’Pure’ semantic markup doesn’t necessarily consider the requirements and consequences of the visual design of the document, after all, the point of semantics is to improve accessibility, not visual appearance. But still, it’s nice to know that in either case you still have equal stylistic control.

Alternatively, If I had included other files in my example, not just images, then an unordered list would make the most sense. But then again, if I was also including the files size and file type, a table would make the most sense if the intention was to compare the file types and sizes, not simply list the files with additional attributes. It’s all very dependent on both the information your displaying and the reason you’re displaying it. It not a simple black and whit decision of table or list.

In Conclusion

So the next time your argue that tables are for tabular data, think about what you’re saying and correct yourself. “Tables are for semantically marking up data in tabular format” as there’s really no such thing as tabular data.

As for the conversation with my colleague, I conclude that my original suggest of a list markup is still correct. Since the purpose of the tool was to list files in a document manager style tool, not compare files to one another, the list is the correct semantic solution.