Nested Tables: The Nodus Nightmare

TABLEs v. DIVs for layout is a classic front-end development fight. As a master of CSS, I consider DIVs to be the preferred method, but I never used to hold it against others for using TABLEs.Both can be done right or wrong. I typically hold myself to the “tables are only for tabular content” standard, and it makes my code significantly easier to maintain.

Even when I go in to clean up a mess left by another developer, it’s not that bad working with TABLEs. I typically get to strip them out and “do it right” from then on. Or so I thought.

Then I met one of my favorite clients. Great company to work for. They recognize the value that they get from my rate, and they are never pushy about deadlines. I rather enjoy our weekly meeting. But I’m basically an extra line of front-end support for their Nodus E-Commerce store, and with their recent “upgrade” I am not sure what to think.

Besides the obvious lack of cohesion and strategy (you can tell just by looking at the code how many different people touched it), some of the JavaScript was written by someone who apparently wrote their first line of JavaScript for Nodus production code (insert cringe here, my fellow JS devs). But the worst part is not the design patterns, or the incompetent JS devs, but the plain old HTML. I mean, really, how many nested tables does it take to make a shopping cart page?

Several, apparently. And not only that, but some of the ASP controls are bound to specific TABLE/TR/TD elements. Ugh. So I have to keep the tables and style around them. No major layout changes for that page! And then there’s the item list for the cart, which is generated in its own table entirely from the backend.

In order to handle some of the deprecated attributes and tags that they inserted along with their tables, they backtracked the master page DOCTYPE to HTML4 transitional (it was XHTML strict prior to the “upgrade”), which is super funny since Nodus is a MS partner, and you’d think they would know that IE10 has a little trouble with transitional DOCTYPEs. I think the tables would have been fine if they had an HTML developer with experience from the last decade, but for some reason (budget, time, etc?) the entire client-side development team did a sloppy job.

Yes, sloppy. I don’t normally rag on other developers as sloppy. I’ve written sloppy code before. I’ve written bloated markup and inefficient CSS selectors. But I have never written tables nested 3 deep (or more!), and though I have used 4.0 transitional to validate some unavoidable deprecated items, I haven’t used an align attribute in at least 4 years. And when I write templates for CMS systems, I’ve been extra careful to write DIV-based layouts so that other CSS devs can come in later to update the design without rewriting markup and/or server-side code.

I hope my other front-end devs appreciate my diligence. This “upgrade” experience has re-affirmed my conviction to meet coding standards, and renewed my own appreciation for other devs that do it too. Eventually, someday, someone is going to need to maintain our code, and we should respect that!