mcville is a community website where you can find smashing interviews
and articles with some recognized people, as well as discussions on
other topics like design,web development, lifestyle, music.

Table Butcher

Jan 15, 08:56 PM by Alessandro

Table Butcher

Table Butcher

Table Butcher on Friday 13


If you’ve felt pain when dealing with CSS to style form elements,
get consistent layouts, paddings or margins across browsers and you
think you’ve had enough, perhaps you’ve never tried to style a table for
layout.


We’ve always heard that tables aren’t flexible like divs for layout,
but has anyone ever tried to import the flexibility of divs into a tabular
layout? In my search for CSS fun, I’ve thought about the fact table cells
are in the end html elements, so it is possible to get a custom layout
independently of the table used, turning cells into block-level elements
with floats or absolute positioning. Things aren’t that easy, though.


In this article I’m going to be sharing this terrifying experience, just to to give you another good
reason for not using tables for layout. The discussion about using tables for layout
is almost over now, but some of the readers could recall Why tables for layout is stupid.


In a six-part saga, I’ll show you the scary adventures of the Table butcher,
as a set of short CSS-and-Javascript based movies trying to achieve the impossible: giving a
twist to a table used for layout, such as visually swapping column order.
The goal is quite hard to achieve for two main reasons. First, and most important, is the
theory factor. The W3C CSS 2.1 specs are quite vague about using floats and positioning on tables:


Positioning and floating of table cells can cause them not to be table cells anymore,
according to the rules in section 9.7. When floating is used, the rules on anonymous table objects may cause an
anonymous cell object to be created as well.


In part, it’s exactly what I wanted to hear; it’s possible to get table cells not to behave as table cells.
But sometimes things aren’t as easy as we may think. There’s indeed the reality factor: while it’s quite easy
to get consistent layouts with divs and CSS, it is quite hard to spin with CSS a
table layout in a cross-browsers way.


That said, before we begin on our adventure, a little disclaimer. The examples I give and anything
discussed here is accompanied with a recommendation: don’t try this at home. It’s meant to be just for fun; in real cases, I
probably won’t use any of the examples I’m going to present, except maybe the last one. Tables aren’t meant
for layouts and furthermore you might have unpredictable results when trying to treat them as divs.
Even if I managed to achieve good compatibility, we don’t know at the moment how four of our examples (numbers two to five)
will behave in future browsers.


Now, we’re ready to introduce the two main actors playing the key roles in each part. Here is the basic
markup:



<table id="main">
<tbody>
<tr><td id="header" colspan=2></td></tr>
<tr>

<td id="nav"></td> <td id="content"></td>
</tr>
<tr><td id="footer" colspan=2></td></tr>
</tbody>

As you can see, no presentational or old-school attributes were used. Here is the other star, the basic CSS:



body{text-align:center}

table#main{width:600px;margin:0 auto;text-align:left}

table#main,table#main td{border:0px solid;padding: 0;

    border-collapse: collapse;vertical-align: top}

td#content{width:400px}

td#nav{width:200px}


Here we go now. The first example, namely Table Butcher on Friday 13, shows
the beginning of the quest: starting from this, I wanted to get a reversed order of the table’s columns.


Next step was trying to float the sidebar. In Table Butcher Floating
in space
I floated the navigation to the right. Here’s the additional CSS:



td#content{display:block}

td#nav{float:right}


The result works perfectly in Opera 8.5, Firefox 1.5 and Safari 2. No effects on Internet Explorer versions from 5 to 6
though.


So what about using absolute positioning? In The absolute return of the Table Butcher
the CSS rules added are:



table#main tr{position:relative}

td#nav{position:absolute;right:0;top:0}


The result is broken as expected in IE, but things are much stranger and unpredictable
in Opera, Firefox and Safari.


So I thought about adding a spin with relative positioning, shifting both columns from one
side to another:



td#nav{position:relative;left:400px}

td#content{position:relative;left:-200px}


The result is Table Butcher and his relatives,
but works only in IE from
5 to 6. Nothing happens in other browsers.


Finally, a little CSS discrimination to combine the float solution with relative positioning
served just to IE, and here’s Table Butcher: beyond good and evil,
which works fine in IE from 5 to 6, Opera, Firefox and Safari. The CSS rules added are:



td#nav{position:relative;left:400px}

td#content{position:relative;left:-200px}

tr>td#nav{position:static;float:right}

tr>td#content{position:static;display:block}

But are there other ways to get the desired result to work consistently across browsers, being
sure that in the future things are as expected? Yes: this solution is to twist the table with a very
small bit of powerful DOM scripting. No CSS additions, but just a three-lines
tiny script:



window.onload=function(){

var n=document.getElementById(“nav”);

n.parentNode.appendChild(n); }


The results can be viewed in Table Butcher and the Mad Professor
and it works in all browsers I used for testing. There are several disadvantages, the main one being
that the page must be completely loaded for the columns to swap, and if javascript is disabled nothing
happens. Besides that, some might say that javascript isn’t meant for layout: all I can answer is
that neither are tables. This is just a way to fight fire with fire.


Finally a few words to conclude. As I said, all these experimentations are meant to be just
for fun and should be considered carefully. The real aim of this article is to show that tables
aren’t meant for layout, and that the consolidated methods that were used in the past are undoubtedly weak
if looked in a more modern way. To recap, here’s the whole story about table butcher:

  1. — Veracon    Jan 16, 03:12 PM    # Please, PLEASE don’t call CSS design ‘using divs’. Seriously, divisions too are unsemantic, and should be avoided as far as possible. It’s not them that are flexible, it’s the CSS.
  2. — Alessandro Fulciniti    Jan 16, 05:05 PM    # Veracon, sorry that you missed the point of the article… that was intended just for fun.

    The topic here is not “divs vs table” or “table or css” but “css applied to a table used for layout”, to show that it’s not that easy as “css applied to divs for layout”.

    Besides, you’d agree with me that DIV are far more flexibles than tables and probably most semantical if used for layout, and most of all are the current way of doing layouts togheter with CSS.

    When we’ll have alternatives, we’ll use them. But now, without divs (or lists if you prefer) the only option remaining is using tables.. a little anachronistic, isn’t it? Finally, you know better than me that 99% or more of the sites you feature on CSS Thesis are divs+CSS.
Leave your comments
Your name:
Your email:
Your website
Your Comment:

Note:Textile is available for use with your comment.






Copyright © MMVII mcville.net © All rights reserved.Published with Textpattern. Hosted by +Plus