The argument over table vs non-table layouts has been going on for years. I remember seeing online conversations as far back as ten years ago on the topic, and given my notoriously bad memory that should be taken as a minimum. Along the way we have dealt with partial CSS implementations, inconsistent rendering behavior, slow implementation of standards, competing proprietary implementations…it’s been a long road.

Table layouts are still in use and in some places they are still the default. They are easy to implement and the browser and standards wars of the late 90’s and early 00’s have left behind a lot of people who remember how impossible it sometimes felt to make a non-tabular layout. However, while there are still browser inconsistencies and delays in standards adoptions, sometimes I wonder if we have forgotten just how long it has been since we started down this non-tabular path.

Table-free Layout is “New”

Tables have existed as part of web standards since the HTML 3.2 standard (January 1997). The standard referenced an earlier RFC and was intended to be compliant with the table tags Netscape had already added to their browser, but this was their official addition to the HTML standard.

The standard pointed out that tables could be used for tabular data or layout purposes, but cautioned that using them for layout would impact accessibility.

In HTML 4 (April 1998), this warning was strengthened to “Tables should not be used purely as a means to layout document content”, and we were pointed to the addition of CSS1 to help accommodate this. It was noted, however, that using deprecated features was expected to continue for a little while in order to support older browsers (browser listed above).

In HTML 4.01 (Dec 1999), this warning was strengthened to the following directive: “Tables should not be used purely as a means to layout document content”.

Tables have existed as part of the HTML standard since 1997, we’ve been warned not to use them for layout, and CSS1 was added to the standard in 1998 to provide layout flexibility without having to resort to tables. While implementation of CSS1 was slow, the inconsistencies we saw between IE4, IE5, and NS 5.4 are a long time back.

If you are interested in the CSS side of the history:

CSS1 Recommendation

was published December, 1996

CSS2 Recommendation

was published May, 1998

CSS2.1 Recommendation

began in 2002 and was published in 2011

CSS3 at Wikipedia

began in 1999 and is a collection of modular standards being published independantly

Out of curiosity I pulled up my personal website from 2002 and checked the source. It was cross-browser compatible and the layout was table-free.

Fast-forward:

Fast-forward:

CSS Takes Longer

There was a point in time when you could spend days trying to get the screen to layout properly. Oddly enough, with the slower internet connections available at the time, it was probably worth it to remove all the extra markup table layouts tend to incorporate.

The amount of time it takes to produce a layout in CSS versus tables has gotten fairly close. With the consistency shown by today’s browsers, the major gap in time is generally learning how to do it. That’s not to say that all is perfect in the world of browserdom, but it’s rare (unknown?) to be forced to use the table option given the number of available examples, prebuilt frameworks, and tweaks available from javascript packages.

Building a house is hard. Can the house builder cut corners to get your house up faster? Sure. But at the end of the day, if the builder is professional they won’t cut corners because those cut corners reduce the value of the house, reduce the satisfaction of the buyer, and increase the ongoing maintenance costs.

The Exceptions

There were exceptions and they got fewer every year. As IE 5.5 and NS 4.6 faded from view, this grew to very few exceptions. Add things like jQuery to the mix and I would be hard-pressed to find an example that required the negative baggage table-layout brings with it. Initially we created fixed width layouts, then along came fluid layouts, then elastic layouts. The latest entry in the game is responsive layouts, where we not only change the overall size of the page to accommodate browser sizes, but also element sizes and flow.

Resorting to table layout immediately means you aren’t treating it as an exception. It’s more likely you need to sit down with your manager or business and help them understand the ongoing costs involved with table layouts, some of the benefits available with newer techniques (ie, 2000 forward), and why it’s important to start making the switch. Luckily there are resources out there to help.

There’s “No Time”

I understand deadlines, the pressure from the business to deliver, and the fact that many companies simply don’t bother to grow their people. As we mentioned before, it can be difficult to convince our managers and business to understand why we need to go the, initially at least, slower route of non-tabular layout.

But you need to go get started. Yesterday.

If your company is hesitant to let you spend the time, point out the costs involved with supporting new browsers as they come out, the advantages of good searchability, the wave of mobile devices that are flooding the market…clean markup can help all of these and there’s any number of sites out there that will provide longer, better articulated lists of costs and benefits (we’ve had a lot of time to think about it).

And don’t forget to point out that since table layouts are contrary to the standard, what you are actually providing to your customer is a defective product.

Moving Forward

When we follow standards, the browser developers can spend more time on new and interesting advancements. When we violate standards, we force them to spend time making sense out of the random, invalid junk we’ve sent to the browser.

Poorly structured, non-standard HTML (like table layouts) takes more bandwidth, takes longer for browsers to render, is more fragile, is harder for experienced web developers to work with, basically forces a rewrite for mobile devices, wastes the time and efforts of browser developers … it’s bad code.

It might be acceptable for a beginner to use tables for layout, by definition a beginner is just learning the ropes. But part of being a beginner is learning and growing past that stage. With non-tabular layouts being around for 13 years, it’s long past the time we, as professionals, start requiring ourselves to know how to use them.