p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: Beginning CSS: Cascading Style Sheets for Web Design ISBN: 978-0-7645-7642-3 (http://p2p.wrox.com/forumdisplay.php?f=154)
-   -   Chapter 10 (http://p2p.wrox.com/showthread.php?t=27397)

czambran March 28th, 2005 10:28 PM

Chapter 10
I am finally at chapter 10, a lot of things are becoming clearer but one question still remains, when is it good to use tables? I know u must be pretty busy but a couple of examples would be great.



richard.york March 28th, 2005 11:30 PM

When you have tabular data that you must show a relationship between.

I mean most people will tell you to avoid tables in a purely presentational application, but in all honesty even that is perfectly fine. And yes this may go a little against the grain of what I said in my book, cause I came down pretty hard on tables in Chapter 10, but (obviously) didn't really say when it is proper and fine to use one (actually I don't recall if I did or not, but obviously there is some doubt). In all truth tables only become bad when they're overused (nest 'em ten deep, and fill 'em to the rim with transparent gifs), especially when better, cleaner, simpler, easier methods exist (Ahem, CSS). When tables are overused a website becomes a nightmare to maintain, it becomes more difficult to tweak the look and feel without breaking the whole thing, it becomes far less accessible (and all that other stuff I said in Chapter 10).

Standards enthusiasts (myself included) often encourage designers to avoid using tables for purely-presentational purposes (e.g. to layout a whole page) because from a semantic standpoint it isn't the best use of tables, and it is also more difficult to create truly flexiable designs (a la CSS Zen Garden[1]) with tables as opposed to block elements like div.

So there is a fine line here, when I say tables are bad I'm saying overusing tables is bad, because it makes a design exponentally more complex than it really needs to be. So if a table is the most appropriate, use tables, don't try to recreate calendars or other tabular data with divs, that's what tables are for, and when it comes to doing a three-column layout or something like that go with divs, those are more flexible and appropriate for that application (IMHO)!

The biggest mistake I personally see designers making is not using the right markup for data, for instance wrapping headings in <p> and <b> tags, that's what <h1> - <h6> is for! Or worse, going to complicated and extreme measures to manipulate space using <p> tags or transparent gifs, when CSS margin or padding is more appropriate. Look at the source of any non-standard designed site and you're likely to find mostly <table>-esque tags and a handful of others, and very little of it will actually add any meaning to the data. Headings won't be in heading tags, paragraphs will probably be separated by line breaks <br />, that is what I'm saying to not do in Chapter 10, avoid making a mess of your markup!

You'll also be interested in Chapter 16 & 17 BTW, where I explore the possibilities CSS offers using tables, and a few seldom used table tags that are actually very useful.

Hope that clears things up.

[1] http://www.csszengarden.com/


Mail_IMAP: A PHP/C-Client/PEAR solution for webmail
Author: Beginning CSS: Cascading Style Sheets For Web Design

czambran March 29th, 2005 09:35 AM

Yes, It definetly did. The reason for my question was that I am building this site for the University I work for, and part of it will be to show the different classes available(PHP) for students, and I thought the best way to show these classes and all pertinent infomation would be to use tables, but then I wasn't so sure because of what u said(more than once ;) ) on chapter10, so from your post I think is probably best if I use tables for this specific situation, the whole layout of the site will be table-free.

Thanks once again.


All times are GMT -4. The time now is 07:48 PM.

Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.