There’s an argument made by a lot of Web design types that a proper site is created using cascading style sheets (CSS) to position the various elements, rather than using HTML tables. They’re wrong.
(I’m not going to go into too much detail about these things here. If you don’t know about ’em, just skip this post.)
The argument for CSS over tables seems good on the surface. With CSS, one file (the stylesheet) defines the structure of the page — header here, navigation here, body here, and so on. A separate file contains the content that’s ‘poured’ into that structure. It only has basic markup (this is the headline, this is the body, etc.) It’s the stylesheet that does the heavy lifting and contains, potentially, a ton of code placing things on the page just so.
This kind of separation of content is great. If you visit CSS Zen Garden you can see it in action. One click changes the stylesheet but leaves the content alone; the result, though, is an entirely different look.
In contrast, if you use HTML tables to define the page, the same file contains the structure (the table’s cells) and the content. If you want to change the look, you have to mess around with that content as well. It’s not as neat.
Or so the logic goes.
Two problems with this.
One: CSS doesn’t completely separate content and structure. If it did, the ‘stuff’ in your content file could be in any order. In fact, the order of items in your content file is important — crucial, in fact.
Putting, say, your “navigation” section before your “sidebar” section can very well give you a very different result than if you switch them. (Unless, that is, every element on the page is positioned absolutely. That can be done, but not many designers do that for the entire page — it reduces browser and screen flexibility too much.)
So using CSS means content is only separated in theory. In reality, you still have to worry about that content file.
More importantly, perhaps, is that for many of us content and design are already separate. We use content-management systems (CMSs). In my case, it’s WordPress, one of the most popular. Others use Drupal, or Movable Type, or Joomla, or… the list goes on.
With a CMS, content and design are separated by definition, no matter what you use to create that design. Tables or CSS, your design (WordPress calls it a template) and your content are in two different places. The template has codes that say, essentially, “put the headline here” and “format the columns like this.”
The template could use CSS or not. I find using CSS to be convenient for many things, but not everything. I think tables do a simpler, better job of defining the overall page structure — I never have a right sidebar disappear under the content because it’s one pixel too large, for example. That happens in CSS all the time.
Tables are incredibly flexible, down to the pixel level just like CSS. In fact, you can use CSS to format tables and cells (table {text-align:center} and so forth). There are fewer browser incompatibilities as well. (There is an argument that tables are harder for the browsers used by the blind to read. But so much of the Web uses tables, I would have to think that those browsers are getting smarter.)
So enough about tables being evil and backwards. I’ve coded a ton in CSS and a ton using tables. They’re both tools in the toolbox, and for anyone using a CMS there’s no advantage to one over the other.
When I write an entry to my blog, or create a page, the text is stored in a database. WordPress then pours that data into my template and you see it.
