Just when I thought this topic was in the past, to be revisited in the same manner as when historians look at how the Black Plague ravaged Europe. But no, it’s back. I’ve had to don my somewhat dusty Web Practice Lead hat at Critical Mass to once again defend the faith from tyranny and the inequities of evil men. (Sorry, sudden Pulp Fiction flashback.) That should read to defend against ignorance. But I digress…
There has been a slight push in the industry over the last few months to return to using tables for web page layouts, rather than the industry standard CSS presentation. Keeping our finger on the pulse of the industry, many of us at Critical Mass have seen the arguments. Some even begin to question our own direction.
This is a good thing, by the way. I want those questions. As Grace Hopper once said, the most dangerous phrase in the language is: “We’ve always done it this way.” Bring the arguments. Bring the discussion. Just come armed and educated.
The movement back to tables is an uneducated position. Despite all the arguments for the movement, the one thing it seems to be ignoring is why the W3C standards exist. They’re not there because a few people thought it was a good idea. They’re there because a group of people far more educated than I spent the time to figure out what the best method would be.
Yes, CSS is complicated. I will completely agree that in many ways, CSS is far too cumbersome for most developers. I will be among the first to stand up and say that support is not complete and correct. I’ll gladly point fingers at Microsoft’s regular aberrant behaviour. CSS is not perfect, and anyone who uses it with any depth will come to realize that there are issues with CSS’s specification (never mind the often haphazard way the browsers implement the specification).
Critical Mass does not represent most developers. We have gone beyond what most developers contend with. Our interfaces are richer and more engaging than the majority of designs out there. We deal with clients who expect results better than middle-of-the-road, and that’s what will drive us to use the right technology for the right reasons.
As strange as it sounds, we work towards segregation: separation of content, presentation, functionality, and structure. This isn’t just the W3C standard — this is common sense. Anyone striving to do proper development, in any language, should be doing this. If you tie the structure to presentation, you’re going to have a fun time making edits when that presentation changes. I’ve seen this happen hundreds of times before. Veterans in this industry can tell you horror stories of having to change the structure of a website across a thousand files, a tedious task that took weeks. Yes, this can be automated, but the connection is the point — it should never occur.
In this article, they split CSS into CSS and CSS-P. This is an interesting, albeit incorrect direction. Critical Mass (as well as most decent developers) adhere to CSS 2.1, which doesn’t break down into two parts. It’s one standard that happens to cover the appearance of fonts and colours, and handle the layout of a page. And that’s what people need to understand.
This requires an understanding of CSS beyond how to use CSS for fonts. From a hiring perspective, we do require that all new hires have an understanding of CSS. While we do not require skills along the lines of Jason Santa Maria, Dave Shea, or Dan Cederholm, although it’s very cool when someone comes in the door who writes great CSS. We do want to see people laying out pages in CSS, even if it’s rudimentary and potentially awkward. Only with that understanding can people learn.
When people cry that “tables are the only way to go” for websites, they have given up on the standards and all the benefits that come along with them. They have opted to cut themselves short on skills and knowledge and allow the site to suffer long-term. I cannot accept that anyone would willingly throw in the towel to lose out on the flexibility of using CSS over the rigidity of tables.
Arguments such as speed, ROI, tables already being in databases, and standards that are too heavy are grossly uninformed. Speed is pointless because any sufficiently complicated design will necessarily have a sufficiently complicated table — and that’s easily larger than using CSS because you have to download the table on every single page. CSS downloads once. ROI is self-defeating because most people only look at the development phase and neglect the far more costly maintenance phase. Well-developed CSS will always allow for faster (hence, cheaper) maintenance. Yes, tables are in a database … and if that’s your argument, you’ve completely misunderstood the need to separate systems. And that’s not a discussion I’m getting into now.
It’s the flexibility that we want. CSS can change quickly (assuming you’ve architected your CSS appropriately) and the same structure can be reformatted with many CSS files. I challenge anyone to show me how to do CSS Zen Garden in tables. And remember, any sufficiently powerful tool is by its own nature more complicated — simple isn’t always better.
All of that said, I do have a concession…
Despite the need to follow standards (knowing why we use them), there is an overriding condition that we must be aware of at all times: We have to follow budgets. And if something is too difficult to do in CSS, we will build it with tables.
Though I will immediately point out (should this condition arise) that if you are going to tables because it won’t work with CSS, that I would question the reasons why. If it’s an infamiliarity with the technology, then more practice might be required. Or that the CSS is already too complex, and there’s a cascade problem. Specificity is important, and the key is to know when to use global settings and when to use specific references.
And of course, we should ALWAYS use tables for tabular data. But you already know that.
So why is this coming up? Why is there the movement back? In a word: AJAX (oh, how I hate that acronym). The last time we had a major buzzword in the Web Development field, it was DHTML. It’s equally as annoying as AJAX because it caused everyone to think a new technology existed. (In both cases, it’s just promoting something that already exists in a novel way.) The buzz has had a positive spin, forcing a lot of previously less-skilled developers to need to learn the standards to implement AJAX correctly. The speed at which people have had to learn is a concern, and those having trouble with CSS are running back to tables.
To those people: slow down. Don’t panic. The solution is there, you just need to spend some time and play a bit with CSS. Maybe you need to do it at home. If you think CSS isn’t worth the time and effort, you really need to think about how you’re approaching your project. I know from my own experience that tables are a dead-end. And if you talk to the best developers in the field, tables are only good for presenting tabular data. Long live CSS.