Question 1 – Tables vs DIVs?

There were a lot of questions submitted to last weekend’s panel Q&A in Dallas that I didn’t have time to answer, so will answer one each day this week. First up, Bill Miller asked:

“Should we aspire to ditch all table/cell markup in pages and use CSS? Are tables still a good thing for pages?”

A: In order- no, and yes. Let me qualify those answers. Tables were originally designed to hold tabular data- any data that is best displayed in rows and columns. In the early years of HTML markup, they also became a defacto way of creating ‘grid-based’ layouts, before CSS was defined and implemented in browsers to help replace tables as a design tool, and provide a better (and more precise) way of laying out pages. But no, I don’t think you should ditch all table/cell markup in pages just for sake of using CSS – but instead use each where their strengths lie. It’s really more a ‘use the best tool for the job’ decision, in my opinion (and trust me, there are some widely-varying and heated opinions on this topic).

In a perfect world (at least mine), your data/text/content would live in the (x)HTML page, and your presentation/design would live in a CSS stylesheet. Clean separation of design and content is the goal. If you’re finding yourself using lots of nested tables and spacer images to achieve a design, you probably should step back and ask yourself how that design could be achieved in a more standards-compliant way using CSS. There’s usually a way to do it that’s more forward-looking than the crusty old table methods of achieving ‘grid layout’ designs, spacer GIFs to force widths/heights, et al. Sure, it can present a learning curve, but the reward is well worth the effort- CSS really is amazingly powerful for achieving just about any visual layout you have in mind, and if you don’t believe me, just go spend a few minutes at Dave Shea’s CSS Zen Garden website. (Dave’s got some interesting points to share in a podcast interview I had with him last March on this subject, too.)

However, if some of the content in your page needs to be displayed in a tabular format, there’s no reason to not consider using a table to contain it. That’s what they were originally designed for, and an absolutely valid reason to use tables in a CSS world. Don’t run screaming from the <table> tags arbitrarily- there’s still plenty of room for tables in a standards-compliant CSS world. But it’s usually more for formatting content, in my opinion, as opposed to realizing your global page designs. That’s where my line is drawn, and I’ve found it a pretty good rule of thumb which has made design updates (especially on large sites) a snap by just updating a few CSS sheets, and kept my XHTML pages clean and uncluttered so they’re less confusing for the less technical folks who may need to update the content within them from time to time. Without access to the CSS, I don’t always have to worry about those less technical clients/editors/etc. blowing out a table cell during a simple content update and destroying my entire page layout! I think you’ll agree, that’s a pretty nice byproduct of moving more towards CSS.

But if you’re new to CSS entirely, it can be a deep learning curve. Start small, perhaps move more of your formatting and styles to a CSS stylesheet first, and then slowly start working at removing those outer nested tables and replacing them with DIVs that you can position via CSS. It’s always best to walk before you run, of course- but once you’re up to full speed with CSS you’ll probably be very glad you made the effort.

And that’s my take on that debate… ;-)

4 Responses to Question 1 – Tables vs DIVs?

  1. Robert says:

    Well said, that’s exactly how I try to explain it to people. I’ve found though, much as you somewhat pointed out, that once people get very deep into css and tableless design they often disregard the fact that tables are still important. Because of that I’d say semantics are an important starting point for anyone trying to grasp the concepts.

  2. Great point, Robert. I also spent a bit more time than I should have trying to avoid tables entirely simply for the sake of saying I had a ‘tableless design’ once I got into CSS. But if you really step back and consider your HTML content semantically, there’s plenty of valid uses for tables besides global page layouts.

  3. John Farrar says:

    Part of the issue is a question of development style and resources. CSS is a HTML vs a server side specification. What that means is that when we adopt a pure specification outlook then we assume that seperation of presentation should be done on the browser. What if we created a seperation layer on the server rather than the browser. If a server side technology could take the content generated by our apps and convert it to a presentation then we would have more presentation than CSS only based presentation layer control. Server side presentation would of course include CSS where it still served best of the solutions, but it would actually give a better senario than browser based CSS presentation. (This is to flexable from browser to browser, there are simpler ways to do things!)

  4. You bet, John- as I noted in my subsequent post yesterday (CSS Efficiency), I’m mostly responding from a client-side approach- and having built many sites with combinations of server-side logic and templates alongside front-end CSS and presentation/layout styles, I won’t argue there are very powerful combinations of client/server scripting and development that can improve on any model. I regularly use PHP, ColdFusion and/or good old Apache #includes for plenty of things, not the least of which being dynamically injecting header/footer snippets and/or sniffing client capabilities to serve out the most efficient stylesheet/JS includes/etc.But in general principle, I still would advocate using CSS for layout- and tables for semantically-sound reasons (i.e. tabular data and content) instead of global designs/layouts. Writing out the HTML (and in some cases, dynamic inline styles within said HTML, or dynamically swapping in CSS sheets based on the client requesting them) via server-side applications does not preclude this general philosophy, either…. ;-)