W3C home > Mailing lists > Public > www-style@w3.org > June 2007

Re: Stylings only possible with Tables

From: Daniel Beardsmore <public@telcontar.net>
Date: Wed, 27 Jun 2007 16:28:26 +0100
Message-ID: <4682821A.20902@telcontar.net>
To: www-style@w3.org

There are different ways to produce HTML. A non-insubstantial number code by 
hand in a text editor. Even with syntax highlighting, it's pretty hard to 
make sense of a table. For tables of data, this is a painful necessity; wiki 
engines tend to replace <table> with even more esoteric and even more 
confusing syntax. A year or two ago, I redid my site template to replace the 
nested tables with pure CSS and the improvement was remarkable: my site made 
sense. I still have many left-over pages whose central content (not the 
template) still has tables and they're still a real bane of my life. I'm 
gradually replacing the tables when I learn how to do so, so I can simplify 
the code.

Fluid grids also have the wonderful advantage of insertion. When I want to 
*insert* an item into a presentational grid, a grid would let me add one 
<li> or one <div> and it would reflow. Tables mandate a lot of reshuffling. 
Very soon you tire of fixed grid layouts when you're only interested in 
presenting a sequence in 2D. Thankfully, you can already (ab)use floating to 
create a simple grid, but there are limitations, predominantly that floats 
don't stack nicely when you have an unknown row length and cell height. 
(When a floated grid starts a new row, the next float sits under the 
shortest cell from the row above, not the start of the line.)

Indeed, I've replaced tables with floated <li>s simply to solve the 
insertion problem. Even with a GUI program I imagine it would be painful to 
insert new cells into a table and shuffle every row down.

I also write server-side code, and again, same deal. Really complex layouts 
with lots of rowspans and colspans would be tricky in code. You have to keep 
the table design down and restrict every single aspect to one cell else 
you'd go mad. Designs with data split into multiple cells would drive you 
insane, especially when you need to rowspan or colspan other parts of the 
site template to match. If each aspect of the site (navigation, content, 
further reading, footer etc) were output as a single <div> it would leave 
the HTML code very easy to style and make the server-side code much cleaner.


At times, in the past, when I used pure HTML and no PHP code or site 
template, I did resort to Netscape Composer to figure out why my table 
designs were not working. It was obvious that something was fundamentally 
wrong when I had HTML code that was too hard to read, too hard to tell site 
content from presentation any more (still true on my site now for some page 
designs that use tables) and when the nested tables were tripping over 
themselves and making broken designs.


The standard automatic table layout algorithm on most browsers is crap 
anyway. iCab used its own, far superior layout technique which I mistakenly 
relied on. iCab has, since, reverted to standard behaviour. Tables aren't 
even very good at being tables, and this ends up requiring ugly hacks to get 
them to do layout.


Tables have been a real bane of my HTML work for years and it's always nice 
to get away from them. I use them when I need tables of information, of 
course, but otherwise, I am not sure what ends up being more painful.


The other snag with tables of course is that you do end up with a rather 
useless site on many non-graphical browsers. The site ceases to make sense 
since you've robbed it of any logical flow.

To me, it's inexcusable to use the bad practices of Web developers as a 
get-out clause for leaving Web authoring broken. CSS should be created as a 
great system for people to use. If people choose to ignore it out of willful 
ignorance and stupidity, that is not our problem. But we should be able to 
say that WE DID OUR BEST to give them what they need. Right now, anyone can 
argue that CSS is too restricted and too broken to allow them to make the 
switch. And that looks very bad on CSS.


I don't know what else to say. When anyone on the CSS Working Group mailing 
list starts to argue in effect that progress with CSS is worthless, 
accessible, clean CSS is of no use and actually harmful, that programmers 
can never be motivated to improve browsers any time this decade so let's 
stop caring, then we may as well pack up and go home. What are we here for? 
To sit around and mope?

I thought we here because we believed in the ideals of CSS, and wanted to 
see it improve? If anyone here doesn't believe in CSS, then why stay here? 
What do you want to do? Shred all our dreams and gloat?
Received on Wednesday, 27 June 2007 15:32:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:51 GMT