Many moons ago when I was just venturing out into the World of web design and development I learnt to code up HTML designs using trusted <table> elements and their accompanying assortment of rows, table data elements, colspans and other such favorites.

Then, only a few months into my web coding journey I read an article questioning whether tables should not be given the “old heave ho” when it came to laying out a screen in favour of the more correct Cascading Style Sheet (CSS). I was sold, the arguments made sense and I busied myself with learning every cross browser, CSS layout trick in the book to allow me to craft beautiful, semantically correct, web pages with not a table in sight. After a while I forgot how to code with tables, and in fact I would struggle to build any page (let alone a whole site) now without my trusted style sheets.

As CSS became fashionable not only to those in the know, but to a wider web building audience (and even to their clients) more and more was written about the evils of using HTML tables for layout and eventually the message got somewhat muddled and condensed, as is so often the case with such things. The message became “HTML tables are evil” full stop. No longer was layout a concern, instead misguided individuals became convinced that web pages should never be tainted by the merest whiff of a table element or any of it’s associates. I have worked with such people.

This is simply not true, and those people are simply not right. HTML tables are useful, versatile and very often absolutely the most correct, semantically appropriate element to use.

They should be used when marking up any data or information that could be deemed a set of some sort. The most obvious occasion would be when marking up some statistical matrix of numerical results, such as a set of temperature readings taken through the day at set time intervals.

Other not so obvious uses may be using them to mark up the profile values of a user (name, date of birth, address, etc) in a social networking site. I’d see this as a perfectly valid use of the element as the rows and columns afforded by the table imply the structural relationship between the values held for the user in question.

There’s even an argument to be made that perhaps the workhorse of the web application world, the humble HTML form may be best marked up in a table. The table providing the implicit relationship between labels and their inputs. I hasten to add that I’m not totally convinced by this train of thought, though after hours of fighting with CSS based layouts of some forms I’ve been tempted to adopt this philosophy wholeheartedly.

So why do I bring this up? Well while searching for a little advice on how to correctly encode some numerical data in a table a few months back I was surprised to find little written on the subject. I have become so used to Googling any CSS related questions and getting a barrage of possible answers, I never stopped to consider there may not be the equivalent for questions concerning tables and their finer details. Don’t get me wrong, there is plenty written on the subject, just little that clearly explains what options you have when trying to code tables correctly (that I could find, or follow).

So I thought I would start a mini series here explaining what I have managed to piece together about the correct, even elegant, use of the most abused element available in HTML.

Next week I shall introduce the elements that are available to the table coder. The following week I shall discuss some of the correct and incorrect uses of said elements. Then in the final installment I shall get really advanced and mix in a little CSS magic to show how data tables can also be sexy.

Stay tuned for more; “HTML tables: Not totally bad.”