Forum Moderators: phranque
I've never had any 'formal' training on how to develop websites. I've been doing it on and off for about 10 years, learning as I go, always teaching myself. I've taught myself html, php, sql, some unix stuff, and just basically whatever I've needed to run a website. At first trying to figure out how to make everything go where I wanted it was a tough job. In addition, I never even heard of css until I was years into making basic websites, and my habits had stuck. When I first started I got into the habit of using tables to structure the pages and make them look the way I want because it worked and was very simple.
I haven't changed.
Why? My question is why should I? I'm not trying to be negative or derogatory to the CSS layout crowd with that question either, I'm genuinely interested in hearing why I should switch.
Tables are easy to create, easy to understand, don't break in different browsers... they just work. I know that semantically they're for data and they aren't designed to be a layout element, but there are examples of stuff like that everywhere. Tires aren't made to be swings and AOL CDs aren't made to be coasters, but if they do the job quickly and effectively... why should I care? My visitors will never notice any difference unless they're technical, which most certainly aren't.
In fact, I have a couple very successful websites of which I'm very proud. Both generate income and both use tables for layout. Both look exactly like I want, both do what I want, and both are easy to work on if I need to make changes. I use CSS on each, but only for styling issues so the CSS is pretty basic and easy for me to understand. I would say that I know CSS enough that I can write a stylesheet that will change the way things look, but when it comes to positioning divs and floating things I'm pretty much in the dark.
It's not that I haven't looked into it, but as soon as I start digging into how to replicate a simple table layout in css I get discouraged.
Tables are just so... Simple. Quiet. Unassuming. Comforting.
CSS is Quirky... Unsupported at times, and even when it is, you have to really tie it into a knot to make it work like a table.
I guess it's just that I don't quite understand why many would perhaps consider me to be an amateur simply because I choose to use tables for layout. I'm by no means what I would consider to be a professional or a guru, but I design sites both on my own and at my job... and I think my peers at my job would consider my work to be of professional quality. Then again, they don't see the code. Then again, neither do my visitors.
When the final result is the same, do the methods really matter so much... at least in this case? I'm not interested in hearing why I'm supposed to do it another way, I want to know what I'll quantitatively gain if I switch.
Thoughts?
----------
banner ¦
----------
n ¦ con-¦
a ¦ tent ¦
v ¦ . . . ¦
----------
Let's say there is nothing in the "content" area.
What you'll see is the border encircles a small area on the screen around the banner. The sidebar overflows the border (as it's removed from doc flow).
Also I found that IE6 (not sure about 7) never really implemented 'bottom' or 'right' positioning so everything had to be based off 'top' and 'left'. Major pain.
Tables took that away as well as letting my page look "normal" when there was nothing in the "content" area. I do have to say though that CSS floating works well to create multi-column pages. I don't know how well it works in IE6 but it's OK in IE7. You just have to make sure the columns are floated in the proper order.
I'm trying to think back on a project I did. I think the problem was IE6 interpreted padding (or margins) incorrectly, which botched the whole thing up... so I did my table thingy... worked fine.
> The sidebar overflows the border
Is your reference to overflow:visible?
> What you'll see is the border encircles a small area on the screen around the banner
Sounds like the behavior of a table to me. I don't do tables. Can you give some example code?
In the code I posted here: [webmasterworld.com...] , the columns can be entirely devoid of content. Point is: the columns don't rely on content to determine their sizes.
Or am I completely missing the point? -- No surprise on my part if I am. <grin>
Re, IE6: You're right about bottom and right. I don't use them.
Re, floats: Too much hassle. I don't use them either.
[edited by: MarkFilipak at 2:14 am (utc) on Mar. 9, 2008]
Tables are used for two reasons:
1 - Cell height grows with content, and
2 - It's easy to center block content between to vertical limits (i.e., columns).
Re, my code:
1 - Does what the table folks said couldn't be done with CSS, and
2 - Meets the objectives.
Of the two sections (top / bottom) of the page that's displayed by the code I posted, the more interesting should be, not the top, but the bottom -- the self-adjusting layout.
Geez, do you want to make ugly 3-column e-commerce sites for the rest of your lives?
There are other metaphors you know: How about a Russian doll metaphor in which navigation takes the visitor inside an ever deeper nest of "sites"? How about a video game metaphor in which the visitor doesn't "go" anywhere but everything comes to him/her and navigation is playing a game? This can all be done with CSS. Locking a site down in a table is just plain boring.
Regarding the bottom self-adjusting section of the page rendered by my code, can you imagine the contents of the NAV, ARTICLES, and ADVERTS sections themselves also being self-adjusting? That's basically how Adobe Acrobat works. That's the kind of web sites I'm producing right now that work in IE6, NS7, FF1, etc. Use you imagination.
[edited by: MarkFilipak at 2:46 am (utc) on Mar. 9, 2008]
-------------
banner . . . .¦
-------------
n ¦ . . . . . . ¦
a ¦ . . . . . . ¦
v ¦ . . . . . . ¦
_ ¦ . . . . . . ¦
_ ¦ . . . . . . ¦
-------------
footer . . . .¦
-------------
-------------
banner . . . .¦
-------------
n ¦ footer . .¦
a ¦ ---------
v ¦
---
So no this has nothing to do with CSS overflow. I'm surprised you don't like floating as it's much less setup and IMHO cleaner then absolute positioning.
Hmmm.... Looks like your nav cell is overflow:visible and the table is collapsing (somehow) even though the nav cell is not empty. I have no idea how that could happen.
Floats are not cross-browser. IE6 really screws them up. Also, when a browser renders this source:
<p>...<div style='float:right'>...</div>...</p> and you look at the innerHTML, here's what you find
<p>...</p><div style='float:right'>...</div>...</p> (note the closing p-tag just before the float -- I didn't do that.)
That closing p-tag really screws up the remaining text after the float.
But my problem with the overflow persists. Hiding the overflow is not really an option..... because it's the navbar. I'd be cutting off content that was intended to be available to users. 97+% of the time the length of the content is > the navbar so there is no problem. It's only a problem when the navbar is > content.
Here's some sample code:
<snip>
Of course this can be fixed with min-height.... but if I remember right IE6 didn't use that properly.... or my side column changed in height too much to be compensated w/that because of expanding/collapsing trees. I can't remember if divs extend if the contents exceed a height parameter is set in CSS. Either way, all I remember is that stuff kept breaking after I thought I had the next solution. After so many attempts I gave up. It's been a little while so it isn't fresh in my memory. But that's why I use tables to create columns.
[edited by: Brett_Tabke at 12:28 pm (utc) on Mar. 12, 2008]
[edit reason] grab another thread dudes....this one isn't about actuall code [/edit]
[snip]
[edited by: Brett_Tabke at 12:27 pm (utc) on Mar. 12, 2008]
[edit reason] take it to another thread guys - this aint about actual code. [/edit]
LOL... with that code, someone should start a thread entitled "Why is using CSS instead of tables evil?"
[edited by: Marcia at 3:42 am (utc) on Mar. 10, 2008]