|
|
|
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
Tables vs CSS
Ok guys,, give me some good reasons why I should use css for page layout as against tables, which is rigid, but predictable across the board.
No flame wars.. just solid reasons. As evidenced by the widespread use of CSS for page layout that obviously causes pages to break and be mangled by the various interpretations of different browsers, why should you continue to use it or even prefer css layout over tables? This should be educational, without argument. ![]()
__________________
webM for $i(0..20){for($j=0;$j<=$i;$j+=2){print pack(qq{H2}, substr(qq{5f5745424d415354415f},$j,2));}print qq{\n};}; |
|
#2
|
||||
|
||||
|
hehe...you asked this question requesting it to be without arguement?!?! AHAHAHAHA!! this threadll be filled with flames.
anyway, with personal experience, css is much faster and less confusing than tables(<table><tr><td></td></tr><tr><td><table><tr<td>....AHHH!!). however, i must also admit that tables are much more promising in the fact that they will hold content in straight rows and columns regardless of anything else. but usually, there are some instances whereas tables become obsulete(sp?). such instances are when youre trying to position an element in that perfect spot right where ya want it. thouhg this is easily done with css using the process of guess and check, it isnt always that great with screen resolution variances. aslo, css isnt always operational with all browsers. but for me, on all of my sites, i use css positioning and also implement tables. css is for the out-of-place positioning and the tables are for aligning elements that simply wont align on their own. and i rarely ever use tables in order for something to look like a table. i usually use it when i have like a form or something where i use one column for field description and the other the input fields. but yes, i do believe you should use css positioning on your pages(though its hell to get it in the right spot), but make sure you use % values, not pixels or something else(may help with different screen resolutions). but along with that, also use tables to organize and/or structure content into rows and columns, becuz, in actuality, css cannot do this prefectly. |
|
#3
|
||||
|
||||
|
So tables win this round, except for the funky positioning bit... where of course you can use relative css within the cell itself to nudge things around.
Load speed is relative to page complexity using tables... and there are ways to optomize table layout. |
|
#4
|
||||
|
||||
Tables still in front after one day!! |
|
#5
|
||||
|
||||
|
In my limited knowledge, tables are the way to go. You know what you're gonna get using them!
Chris
__________________
Pop, pop, fizz, fizz, oh what a relief it is! |
|
#6
|
|||
|
|||
|
Short answer: Tables.
I found <div> tags to be virtually useless in practical design when it comes to replacing tables. Well not so much useless, they just made things so irritatingly complex to the point that using tables seemed like a dream come true. I had made a simple layout using tables in about half an hour, completely finished and styled. But I decided that it was so simple that a lot of it could be converted to divs instead of all the unnecessary cell-upon-row-upon-table tags that I had created. So I spent days attempting to replicate it, tweaking widths and margins to within 0.1%, honing the save source - change window - refresh - quick scan of layout - cry - repeat cycle into an art form - I could actually go from Ctrl+S to tears (metaphorical tears of course) in under 2 seconds by the end of the first day. In the end I managed to get close to the original table layout, it took about 9 work hours in total, and I'd ended up with more nesting than the original. Cue crying... The point my long and curiously depressing story is getting at is that you'll probably be better off using tables. If you can make it with tables and it works, just leave it and be glad. divs are nice for some things, but replacing tables just doesn't seem to be one of them. They seem like they could, even now when I look at that layout's source I think "if I just tried such-and-such I could get that to work", but then I see the HTML comments strewn about the source warning me against even trying to use a <div> layout again and I decide to leave it. Actually I use CSS for all the styling that I apply to the table, but I use the table for the structure of the layout which I assume is what you want to know about. Note: I use XHTML 1.0 Strict for my layouts, this might not be true for Transitional of HTML4.01 documents. |
|
#7
|
||||
|
||||
|
I'll take the CSS side of this argument.
Here's why I think people still use tables: 1. B/c they're used to them. They've always used them. They know how to use them. If they can invision it done, they invision it done in tables. (leads into #2) 2. B/c they don't design a site with CSS layout in mind, they design with a table layout in mind. 3. B/c they don't know what they're doing when it comes to CSS layouts and don't want to take the time to learn. Yes, CSS layouts are squirrelly from browser to browser (mainly b/c M$ can't read), but there are fixes. Once you've learned the fixes and can do them w/o thought, there's no delay in production -- just like adding that precarious spacer cell in your table. And you can even design sites w/o worrying about the fixes if you do it right. CSS provides overall less code which means it's easier to maintain and uses less overall bandwidth. Nesting example: Code:
<!-- no thanks -->
<table>
<tr>
<td>
<table>
<tr>
<td>foo</td>
</tr>
</table>
</td>
</tr>
</table>
Code:
<!-- yes please --> <div> <div>foo</div> </div>
__________________
# Jeremy Explain your problem instead of asking how to do what you decided was the solution. |
|
#8
|
||||
|
||||
|
Point taken Jeremy ... but those divs need supporting css.
Bottom line is that youll have a jungle of code elsewhere that you cannot visually and readily relate to those divs.. especially when looking back at the code 6 months later If you then put the css at the div level in the code, then you have even more confusion than the table HTML, ... not forgetting trying to capture the layout by memorizing co-ordinates. .. no? Not taking sides here.. just bringing out some points to consider. |
|
#9
|
|||||
|
|||||
|
Quote:
Quote:
Quote:
|
|
#10
|
||||
|
||||
|
Jeremy has a point there....though, i must admit, at times, absolute positioning with css can become quite the tedious activity....and thus, i fall back onto my first conclusion: tables should be used for 'straight' positioning while irregular positioning is to be dealt with by css positioning methods. also, yes, i agree with Jeremy again; css provides an easier way to code to make your code more organized and clean. this especially is true when you link your pages to a .css file. this cleans up your coding even more by simply sacrifices such space and organiztaion within a .css file thatll never have to be drastically edited again after the first modification. however, i have found amethod of convenience for people linking their pages to an external stylesheet: for positioing, use inline styling. in other words, your .css file should contain things such as color, font, background-color, etc, and your tags should have styling variances such as positioning and width and height. this makes it easier to guess and check for element positioning becuz it is easier to edit within a page instead of editting another. but, again, i must say that im not taking any sides here...becuz i find it even better to simply combine the two together, becuz in doing so, you are allowing the good organizing created by using tables, and the great positioing and styling options provided by css.
|
|
#11
|
|||
|
|||
|
CSS takes a little to learn, but worth it
I'm a new CSS fanatic. I find it more flexible than tables and nested tables. I use external CSS files, and validate both the CSS & HTML in the W3C validators.
One reason for using CSS instead of tables is that CSS lets you put critical information at the top of your page code and masthead & navigation tags at the bottom, even though masthead & nav are displayed at the top of the page. For search engines that consider the location of the keywords on your page in their algorithm this can give you a slight edge, provided you are doing everything else you should be doing. If you look at your pages in text browser, such as Lynx, you'll see what I mean, but I'll try a short example. Lynx shows you what the search engine sees. One of the sites I did with tables looked like this in Lynx. It has a masthead with some nav links under the masthead and others on the left. logo.gif inline (graphic) inline (graphic) nav-link nav-link nav-link nav-link nav-link nav-link inline (graphic) link link link link heading sub heading Critical text withkeywords text with keywords text with keywords text with keywords ============= The site with CSS positioning looks like product name (logo is now text effect) subhead Critical text with keywords text with keywords text with keywords text with keywords (graphic) inline (graphic) inline (graphic) link link link nav-link nav-link nav-link nav-link nav-link nav-link I'll admit it took me a little while to sort it out. But then I found a new book on the topic that explained CSS positioning to me in a way I could understand and implement it. And with that book it took me about 7 days to work through the examples and then design a new site from scratch. If I want to I can basically enter what amounts to XY coordinates for each DIV. With CSS you can even make navigation buttons look like buttons with a rollover, even though they are just text with a shaded background. No scripting. No images to download. You can position an image and wrap the text around it with a "style: float" markup. That said tables have their uses. For example a matrix. |
|
#12
|
|||
|
|||
|
FYI
Pro-Tables Web Page. Warning! If you are pro-css, you could be offended. |
|
#13
|
||||
|
||||
|
Should I pick that apart in general or in detail?
|
|
#14
|
||||
|
||||
|
That article would shock the guts out of the fainthearted CSS fans...(wont budge a dinosar like Jeremy though ) I walk both sides of the fence and can relate to many of the points... been there, done that .. (although its a pro table article - its pratical)... One important point which holds true for any type of construction, whether it be a web page or a yatch... it all starts with boxlike grid... hence the CSS chaos and confusion when positioning for different resolutions and vi |