Ionrock Dot Org

There has been a good deal of talk within the design community about css only design. The most obvious complaint that many new to css find is that there is no easy way to make columns. While many css gurus disagree with me on this (no, I haven't spoken with any of these people... yet), I do not feel that it is an easy task. So instead of reviewing the numerous articles, templates, examples, etc., and offering the be all tutorial for creating columns to your hearts desire, I will instead speak a little database speak and refer to the lone tuples and relations that make up what many believe define what a column actually is. You may be guessing at the moment that I am going to contradict those designers that actually have something to show for thier design prowess and in this case you are right. But I do believe I have a very compelling argument as to why we need to take a better look at the "table" as an appropriate tool to create semantic mark up that makes sense in more worlds than the web alone.

To begin we will look at any web developers best friend, the relational database. I want to point out that the relational side of this is very important since without it we are merely speaking of an excel file or spreadsheet. In a relational database the planning is key to creating a database that is flexible, scalable and just plain old fun to work with. To plan an effective database one needs to think about the different relationships data has to each other. A good example would be a persons name and phone number. One person may have one phone number that is strictly their own. Another person might share a line with the whole family in which case each person would have the same phone number. We see a relationship there and it becomes very important to consider how to place this information in a database because it would be a tragedy to lose my phone number just because my wife leaves the database for whatever reason. Why is all this important to design you ask? Well, when you design a database you are focused on creating a good schema, or in other words what columns are going in what tables. A good design allows for amazing things to happen that you never thought about and that is what creating a database is all about, a full proof design that unknown data can happily live in. I know I still haven't answered why the heck this matters to designers and css in particular but give it a little time and we will see all things come into focus.

There are many ways to plan a database, E/R models, Object Oriented Models, Relational Models, MIUAYGA Model (Make It Up As You Go Along) as well as many others. Once you get your plan together you begin to test things out by looking how things relate and if there needs to be changes. What happens is you rearrange columns in tables to make things work and make data easy to access while making it hard to get rid of important info. To relate this all back to design, I want to make clear that designing a database revolves around columns in a very similar way that printing and the web has focused on columns. Columns organize and separate to make information clear to the reader. Columns can be used to provide different opinions or allow easier readability so a point is easy to understand. Without at least one column you have a big bunch of nothing and that is no good to anyone.

So now that we know how important columns are to our data both in the database and on our websites, I pose the question, why is it that in a datbase columns and rows meet to form tables and in web design columns and rows meet to form big piles of crappy designed, unsemantic markup? I agree that tabular data should be placed in a table but I want to know who is defining this tabular data. Who gave that guy/girl the right to tell me that my data should not be in columns or rows and that I had to divide my content up like crazy and play mind games with browsers just to make three stupid columns on a page that some browsers won't even display? Again, I want to make it clear I agree with the catch phrase of keeping tabular data in tables but I would argue that our content as a whole is meant to be in a table if it is supposed to be in columns. Just because a there are not numbers and stats doesn't mean that the data is not tabular. Any person who has worked with a database quickly sees that a database holds all kinds of data from simple text to binary files. All of it belongs to a column and a row and the world is a better place for it. Maybe we need to reconsider then why we have stripped our layouts of their needed structure and functional solution.

Now I realize this may sound like the words of a lazy developer who doesn't to take the time to learn the intracacies of css and its purpose to separate content from design. This is anything but true. I have been a staunch advocate of css to the point of making clear to my professors intro to html that their primitive views of using tables for layout were false and would end up ruining all the students chances of ever truly understanding the web and how it works. I was a believer in no tables makes for better designs, period. I found though that in my work I rarely had the time to make all my designs free from tables due to the limited financial capacities of my clients. When I began working more with issues regarding templates for content management systems and allowing for multiple designs to be created and maintained for many different types of data, problems quickly arose that would not seem to go away.

The obvious argument one can pose in the face of the developer who is making an effort to be standards compliant is that with examples such as css zen garden, there is no limit to how much one can do with css. While I do respect css zen garden a great deal (and I mean great), it relies on static markup. The problem with this is that very little companies pay thousands upon thousands of dollars to get 20 - 50 html pages that have to be updated by hand. Websites all over the web are created using databases and xml backends to store data. It is in the database that you will find the real division of content from layout and design. By placing your content in a database you have the flexibility to do whatever you like with the ouput whether you need the article in LaTeX or a simple html table. This example is most often the case for large sites that have enough content that really does need organized markup where css is truly a way of life to make changes anywhere near manageable.

This issue of designing web pages so they can handle any type of data is similar in the way databases must also allow for all data, both known and unknown, to be added. Where it is incorrect to use tables is the areas where you are not using the table for data. The best example of this is the dreaded spacer gif which is placed in a table to make sure things are spaced correctly. Another example would be the use of colspans and rowspans to make the layout correct. Yet another example would using tables having nothing in the cells and use a width or height to manipulate the design. The main point is that tabular data is not only data that needs to be in a spreadsheet but rather data that needs to be divided by the constructs of a table, namely the row and column. Since xhtml and css provide very adequatly for the instance of a row without many problems, it is really only the issue of columns that would even need to be utilized in most scenarios.

So, if you have kept up with this enourmously long rant, then congrats and you can start looking for something else to do in just a minute or two. The issue of creating columns using css has been solved many times over and while these solutions are all valid and admirable, I would still consider them hacks. We now criticize the use of javascript for our mouseovers since css provides a better solution. This is true because it is an elegant solution that is simpler, faster and easier to understand. But, when you consider the work and time spent on making columns using strictly css, I think we see the same kind of creative solutions that while technically viable and interesting, are still hacks. A table with three columns and one row is a much more elegant way to display three columns on the page. This is especially true if the data within the columns comes from a database or xml file. This is also where a table is more semantically correct as well since an actual table implies the use of columns when css and divs do anything but.

This brings me to my last point, the future of css. I do believe that a table is really not the best way to create columns. I agree that using a tool like css is a better solution but the problem at the moment is css does not offer this solution. We need to push the limits but I believe that forcing our friends over at mozilla to make the effort to render our css masterpieces correctly when the problem could have been fixed with 14 tags is just a little mean. Also, I do not like the idea of css that needs to decoded to make sense of everything (I realize that comments and structured css solves this but css is far from a programming language and should not behave as such). Some day css will offer the solution we need to create columns like our friends in the print industry have. Some day you will be able to make text break at the end of the window and head up to the top of the next column without breaking a sweat and without worrying about the size of the browser window. But until then, I think we should give tables a break and go ahead and use them for what they were created for, making columns and rows.