There’s no shortage of material in the web-ranks that points to best-use practices of coding a website in a proper, semantic way. Semantic, basically meaning the idea that your content should be separate from the way it is presented to the computers that display your work. Creating a website with logical semantic code, often means that your website fares better in a number of areas:

Pages have the ability to be far more flexible for each device that accesses them

Page load times are often shorter with well-written code

Search engines — like Google — mention well-written code in their documentation of ways to rank higher in their results

Code-nazi’s sleep better when you abide by the rules written in their books and they don’t call you out in the blogosphere

Disclaimer: I am all for best-practices in everything I produce. Whether in design or development, I try to always take the path of least resistance but not at the expense of cutting corners. I prefer to develop my sites with semantic HTML.

A history lesson

When the Internet was a young pup, building websites with a table-based layout was great. Developers had a grid easily at their finger tips and everything fell into place. As WYSIWYG editors like FrontPage and Dreamweaver came along, the ability to click a couple of buttons and drag your content into place was a dream. Need to join a couple of cells just like you would in Excel? No problem. Need a whole row or column? Easy. At the turn of the century, almost everything on the web was wrapped in some form of table with inline styling code to get items on your page to look exactly right. And this was OK.

The code behind a site was long and unruly but the limitations of browsers at the time made it the standard for developing on the web and nobody knew any different.

Thankfully the people behind web standards (W3C, etc) and browser manufacturers (Microsoft, Netscape) didn’t sit on their laurels and watch everything become stale. Through concerted efforts they pushed forward with ideas of a semantic web through new languages/technologies like CSS.

As CSS was developed and adopted, it became smart to separate your page content (what you’re currently reading) and your page structure/styles (the layout/colors). A new wave in web creation was starting to catch on somewhere around late 2002 to early 2003. Books were printed, conferences were started, blogs were in full swing and you were more than likely to be called a hack or similar if you didn’t jump on the semantic web bandwagon.

Tables became low-rent where as CSS was the penthouse. The ability to tie a stylesheet to your website was a treat and the ability to target certain browsers was a blessing (until everyone realized that it was purely for the sake of rescuing Internet Explorer). Layouts no longer had to conform to a certain grid and you started to see some real innovation in designs. Tables had been put into their place and allowed by many only for one purpose, storing data.

As our device innovation grew, so did the need for flexibility in our websites. The development and adoption of CSS made the transitions to most of the new mediums relatively seamless where table-based layouts would have struggled mightily. First was the printer and their counterpart the print stylesheet. Then came the larger monitor and thus our designs grew as well. Not too far after we all grew the display size of our websites, laptops became more widely accepted thus making us rethink our need for larger displaying websites. The hand held PDAs like the Dell Axiom, Palm Cliq and Handsprings of the world. Now what? CSS to the rescue. The mobile world was spun on its head in 2007 by Apple and others quickly followed with the ability to view our sites in more ways than one. Full screens, mobile versions, zoomed in and more. More stylesheets. Thankfully with their latest invention, they realized our eyes get worse as we age and decided to increase the screen size this time around.

Through most of these hardware innovations though, sites built with tables as their framework probably suffered in some form or fashion. Either squished content, horizontal scrolling of content or worst of all, no content.

In the end, I am grateful for the advances of the web through technologies like CSS, JavaScript and yes, when appropriate Flash.

I code in tables

With all of that said, I code in tables.

First off, let’s get this out of the way, clients don’t care. If it shows up well on their screen and is close in all of the major browsers, they’re happy. It doesn’t matter to them if their site can pass the W3C Validator.

Second, I don’t code all of my sites in tables, only certain ones. And only because the tools I have at my discretion for the project call for it.

One of my clients has a custom CMS. The tool itself works well and has some 200 or more clients that use it daily. Development of the CMS started some time around 2001 in the pre-CSS web era. Over the next decade it has grown immensely with modules that range from photo galleries to blogging and calendars to real estate packages with MLS incorporation. These and many more are all available to turn on at the flip of a digital switch. As with most any technology, it has flaws as well and one of its biggest is that it is a fan of table-based layouts mainly due to the age of development.

I don’t code all of my sites in tables, only certain ones. And only because the tools I have at my discretion for the project call for it.

I’ve fought it. Many times over. I used to rant daily about it but have learned to work within its confinements as much as possible while still utilizing best coding practices and minimizing the use of tables to the least amount possible. Though it isn’t a perfect solution, you realize that when you have a system with 200+ businesses counting on their stuff working everyday — from shared code no less — you realize that the sum is greater than the individual parts.

A quick technical explanation for those who might care is that the CMS builds the content area in sections. Each section adds a new row. A row must reside in a table. Thus, I build my sites with semantic code and then wrap only the content area and the navigation in tables. That’s two tables (not nested) that I insert into my code to make all new sites behave nicely without offending current sites on the system. On occasion (as the design permits), I can even eliminate the need for a table on the navigation resulting in a single fixed width table around the content area.

It’s not a perfect solution but it is one that works. My styles still reside in their own CSS stylesheet and my layouts are still controlled by floating divs. But today, I confess to the community, that I code in tables.

For my confession of “improper coding,” I might get punished. And without knowing for sure, I think I might have already been. More than once.

In the last couple of months, I have been approached by a couple of different firms looking for somebody to come on board to help them by doing what I do, for them1. It’s only by coincidence that they both happen to be in New York but I don’t think it’s by coincidence that after speaking with people from both firms and pointing them to my portfolio that radio silence commenced. My initial conversations with both companies went well including multiple interactions with each and the signing of some paperwork to promise that I wouldn’t disclose any of their secrets.

With one of the firms I had multiple exchanges with the lead designer and with the other was the lead technologist. Once it was time to move forward I was promised a conversation with a/the lead developer to discuss further. My contact info was forwarded and that’s where our discussions have ceased. I have attempted to follow up with each one but my correspondence seems to fall on deaf ears.

I have no way of knowing the exact reasons, but one I thought I keep coming back to is the fact that in my portfolio are a number of sites coded with tables. If that is the case, it only saddens me that I never had the opportunity to explain or share the details behind each website. I suppose this will have to suffice.

Which makes me wonder, how often do I give the benefit of the doubt? Rarely, at best. In court it’s innocent until proven guilty but in the court of public opinion it’s quite the opposite. I am guilty of using tables in my code but it is only half of the story. I have been hired to provide a service, working with an existing platform for a client that only cares that their product works as advertised and is presented on time.

I’ll take guilty and feeding my family over innocent and starving every time.

Footnotes1 I am not currently seeking employment. I am, however, always open to chat if you think you have the perfect situation for me and my family.

RSS readers: I’d encourage you to click through, this post is best viewed in the browser.