- From: Daniel Beardsmore <public@telcontar.net>
- Date: Wed, 27 Jun 2007 16:28:26 +0100
- 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 UTC