Sell me on CSS-Layouts.
Moderator: General Moderators
The problem some "pro-tables people" have is indeed the mindset. If you start thinking about a photoshop-comp with some table-like grid and you start applying that to "a div layout", you already started in the wrong direction. And you'll never get a satisfactory solution. You're just replacing trs with divs. No point in that.
But once you've changed your mindset and start thinking differently about documents/resources on the web (ok, call them pages) it's different. And when you've experienced redesigning a site build in CSS, you're also sold. I've gone through a couple of redesigns om my own and others sites now, and with css it's a breeze. Hardly a need to touch the HTML.
A few good books are Bulletproof Webdesign (dan cederholm) and CSS mastery (andy budd et al).
But once you've changed your mindset and start thinking differently about documents/resources on the web (ok, call them pages) it's different. And when you've experienced redesigning a site build in CSS, you're also sold. I've gone through a couple of redesigns om my own and others sites now, and with css it's a breeze. Hardly a need to touch the HTML.
A few good books are Bulletproof Webdesign (dan cederholm) and CSS mastery (andy budd et al).
I will admit I usually approach things starting off with tables then try to make a CSS equivalent (and more than often fail). But look at this mockup:

Red sides are those that shouldn't resize, green are those that should.
In a situation like this, why would I go with a CSS layout when tables work perfectly fine?
In the previous example I stated, I neglected to explicitely mention that the <divs> my friend used were laid out exactly like I laid out my <table> & related tags - so I wasn't gaining anything in the "just change the CSS to change the whole appearance of the site" department. I will acknowledge that for a lot of sites that is a viable solution & in those cases ya - CSS makes sense. But in this situation, and other (read: all) situations where I've wanted a fluid layout with static width elements - tables seem to be about the only thing that work easily.

Red sides are those that shouldn't resize, green are those that should.
In a situation like this, why would I go with a CSS layout when tables work perfectly fine?
In the previous example I stated, I neglected to explicitely mention that the <divs> my friend used were laid out exactly like I laid out my <table> & related tags - so I wasn't gaining anything in the "just change the CSS to change the whole appearance of the site" department. I will acknowledge that for a lot of sites that is a viable solution & in those cases ya - CSS makes sense. But in this situation, and other (read: all) situations where I've wanted a fluid layout with static width elements - tables seem to be about the only thing that work easily.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
That's an opinion & one you're completely entitled to. However that "moral" standpoint, I don't feel, is convincing enough to be the sole reason to not use tables.matthijs wrote:...it's not the right thing to use a table...
...it's the right thing.
@~JellyFish - I believe your original topic was answered to your liking, that's why I'm kind of hi-jacking this thread. If you want, I'll stop.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Accessibility is an important thing to consider - you're right there. From the sites I've seen though, a modern screen reader wouldn't have any more difficulty reading this:Jcart wrote:Accessibility is a big reason to switch.. screen readers have a much easier time with css
Code: Select all
<table>
<tr>
<td>
</td>
<td>
This is my body
</td>
<td>
</td>
</tr>
</table>Code: Select all
<div>
<div>
<div>
</div>
<div>
This is my body
</div>
<div>
</div>
</div>
</div>Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
-
nickvd
- DevNet Resident
- Posts: 1027
- Joined: Thu Mar 10, 2005 5:27 pm
- Location: Southern Ontario
- Contact:
I've mentioned this before, and I think it's the best way to (partially) settle the table -vs- css debate.
I'm a huge proponent of the standards, css, and all that. I also know when it just doesn't make sense to use css for major structural pieces.
It all boils down to who the site is being designed for, not the audience (though accessibility should always be adhered to), it's the owner of the site, and their budget. Sometimes, depending on the design, a css based layout can take longer to create over a table based design. If the client is not willing to spend the money, despite being educated about the reasoning behind it, then we need to churn the site out quicker, and sometimes that means using a table for the main structure (columns, header, footer etc...).
Using a single table to lock down the key structural pieces and then using css for everything else won't be all that different than using divs for the structure (<div id="header"/> <div id="left/right"/> etc..) and css for the positioning. It may even be fewer overall characters due to not needing as much css (and possible hacks) to make it work the same as a table.
Tables look the same across virtually every browser. Therefore, we don't need to test the layout in 7 different browsers and across 3 different operating systems. This can really speed up the development process greatly and therefore save the client some money.
That being said. I never use tables (for layout) on my personal projects, I'm not really paying myself for my work, so I don't mind the extra time it takes
I'm a huge proponent of the standards, css, and all that. I also know when it just doesn't make sense to use css for major structural pieces.
It all boils down to who the site is being designed for, not the audience (though accessibility should always be adhered to), it's the owner of the site, and their budget. Sometimes, depending on the design, a css based layout can take longer to create over a table based design. If the client is not willing to spend the money, despite being educated about the reasoning behind it, then we need to churn the site out quicker, and sometimes that means using a table for the main structure (columns, header, footer etc...).
Using a single table to lock down the key structural pieces and then using css for everything else won't be all that different than using divs for the structure (<div id="header"/> <div id="left/right"/> etc..) and css for the positioning. It may even be fewer overall characters due to not needing as much css (and possible hacks) to make it work the same as a table.
Tables look the same across virtually every browser. Therefore, we don't need to test the layout in 7 different browsers and across 3 different operating systems. This can really speed up the development process greatly and therefore save the client some money.
That being said. I never use tables (for layout) on my personal projects, I'm not really paying myself for my work, so I don't mind the extra time it takes
pickle wrote:matthijs wrote:That's an opinion & one you're completely entitled to. However that "moral" standpoint, I don't feel, is convincing enough to be the sole reason to not use tables.
O well, of course that "moral" standpoint is based on all the underlying rational reasons. Accessibility, maintainability, SEO, etc etc. I was just too lazy to tyre it all out..
Interesting aspect though about the screenreaders. I do know for sure that a bunch of tables is annoying/inaccessible for someone using a screenreader. I don't know about divs though. I don't think a screenreader reads all the divs. Probably only the semantic elements. That's why a table is read aloud (would be useful if that table is in fact used for tabular data, which might be important). Or headers. Or links.
Also, someone using a screenreader can choose to listen to all the links on a page for example. Or all headers. To get a good overview of what's on the page. That's a reason to use good link text by the way.
Nickvd, I can understand your point of view. And if you do it wisely and use only a single table to hold together a few main parts of the website, well ok. That's something Jeffrey Zeldmann talks about in his book, as a transitional way of building sites. We should not forget that other aspects are important as well. Using semantic markup, skip-links, good link text, headers, unobtrusive javascript, etc etc.
So I think we will still be able to go through one door together and even have a beer or two
There are some things made easier with tables. Like table-data's valign attribute. How would you mimic that in a div? I googled it and all I found was some absolute positioning techniques. Like:
This is okay if the content within the container isn't too short or too long.
What other ways are there to vertically and horizontally align content using CSS?
Code: Select all
#container {
position: absolute;
left: 25%;
top: 25%;
width: 50%;
height: 50%;
}
What other ways are there to vertically and horizontally align content using CSS?
Yes, absolute positioning can work.
To give an example. But which technique is best depends on many things.
Another thing in this discussion is that with designing for the web, for some people it's difficult to accept that you cannot control everything. Especially something like the vertical spacing/alignment/placement. Each system, device, browser, window, user preference is different. So just forget that you can control exactly how something looks. You just cannot start with your nice little 1024x600px frame/window and place your little boxes pixel-perfect in place. Just let it go. It's ok.
What's more important is scalability and flexibility. Let the content flow and find it's place. With the right methods (for example using em/% for size/margins/paddings) everything will stay in proportion nicely, no matter what content, device, browser etc.
If you study the examples in Bulletproof web design from Cederholm you see what I mean (Jellyfish, that book is a must-have).
This might all be a little abstract, but my point is that often when people show me examples which are difficult to make without tables (or even frames!) it's because these examples were designed with a different starting point in mind.
Code: Select all
#wrapper {
position:relative;
padding-bottom:4em;
}
#footer {
position:absolute;
bottom:0;
height:4em;
}
Another thing in this discussion is that with designing for the web, for some people it's difficult to accept that you cannot control everything. Especially something like the vertical spacing/alignment/placement. Each system, device, browser, window, user preference is different. So just forget that you can control exactly how something looks. You just cannot start with your nice little 1024x600px frame/window and place your little boxes pixel-perfect in place. Just let it go. It's ok.
What's more important is scalability and flexibility. Let the content flow and find it's place. With the right methods (for example using em/% for size/margins/paddings) everything will stay in proportion nicely, no matter what content, device, browser etc.
If you study the examples in Bulletproof web design from Cederholm you see what I mean (Jellyfish, that book is a must-have).
This might all be a little abstract, but my point is that often when people show me examples which are difficult to make without tables (or even frames!) it's because these examples were designed with a different starting point in mind.
matthijs, that is so true. A lot of people just can't get over the fact that things do not need to be PIXEL perfect on a web site. The internet is a much different medium than print. This is a concept I'm having a hard time convincing my bosses of. They are print designers, so they think that everything needs to be placed exactly right on a web layout. They forget that when building a website, you're not just building something pretty... it has to be USABLE as well, and that has to come first.
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact: