DIV has some clear advantages over the dusty old TABLE. Ufortunately, TABLE also has some advantages over the shiny new DIV. Here is my personal point list: DIV The content is seperated from the presentation The code is shorter, saving maybe 5 kb in loading time ... Newer = more shiny. TABLE More stable across multiple browsers Designed especially for building tables, making it superior for table-style layout. Older = better implemented. I know that it feels more "correct" to use CSS all the way. But is it really the superior choice?
Yes it is. The whole world has adopted it as a standard pretty much and that wouldn't happen in tables were so great and wonderful!
Godamn. Some guy asks this question every single day on either Sitepoint, Digitalpoint, or some other form when he can either google or search the form, because its been discussed hundreds of thousands of times. Anyway, 5 kb?!?!?!!? Maybe on a tiny, tiny site but if you take a huge site like Yahoo or Google, every byte on each page (out of hundreds, thousands) saves bandwidth and saving bandwidth = saving $$$. I suggest you read why tables for layout is stupid. You shouldn't be thinking of what's new and what's old, you should be thinking of why one would be better than the other. When you get past the novice CSS level and familiarize yourself with browser bugs (particularly MSIE) you'll without a doubt know for sure that tables for layout are a thing of the past, and a BITCH to maintain. Most people who still use tables for layout are those 30-40 year old "veteran" developers who've been doing it for the last 10 years and don't keep up with the web. If you want to go that route, go ahead but seperating your content from presentation will be beneficial in the future, and it's much easier to maintain. Also, just because you use DIVs doesn't mean you *completely* seperate content from presentation. There are many novices who still don't get the whole point and still use presentational classes, presentational elements, bloated markup ridden with classitus, divitus, etc.
Table should be used for "table" data, not for layout. For layout <DIV>!!! It is true that "table layout" is simple, but... using tables for layout is not HTML semantic valid.
For layout it's NOT just "DIV", it's the appropriate element whether its a ul, div, table, dl, etc. You want to avoid divitus.
soulscratch is right - also don't forget that some elements are considered "block-level" and others are "inline" - you NEED to learn what they are and how they work before you can even THINK about using CSS properly. After that, you'll be learning about the document object model (even if you don't realize it).
Learning to read a DOCTYPE had the single largest impact on what I know & how fast I learned. There's alot more to it than just <div> and <table> like soulscratch mentioned. If you've never done it before, open this Document Type Definition in Notepad or any other text editor. http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd You can do this with the addresses which look like that in the DOCTYPE lines you find in other webpages, but for the sake of example just use the provided XHTML DOCTYPE for now. To help you get started, here's a few hints. If you have any basic knowledge on Regular Expressions, bring it with you. If you don't, it's only basic usage of them so you should be fine for the most part. The following works like a variable, basicly. <!ENTITY % coreattrs "id ID #IMPLIED class CDATA #IMPLIED style %StyleSheet; #IMPLIED title %Text; #IMPLIED" > Code (markup): The first line, "<!ENTITY %" denotes the beginning of a variable, followed by the name which will be used to reference the variable later on in the DTD. However, later there will be no space between the % and the name. To reference the variable, or entity, works the same as using say, & or would. In the case of the example entity, it would be %coreattrs; You can kinda see how they're referenced in the last couple of lines in the example. Those two entity references refer to entities defined earlier on in the DTD. Note that these references ARE case-sensitive. "%block;" is not equal to "%Block;". Now, the second line you see the familiar "id" attribute, some whitespace, then "ID". "ID" is a data type which basicly means any valid identifier, generally anything valid to use in a variable name in somthing like PHP, or JS. The other one, "CDATA" is Character Data, which is pretty much any valid language character. After some more whitespace you see "#IMPLIED", that basicly means it's allowed, but not required. There is a "#REQUIRED" & that means exactly what it sounds like. Now further down in the DTD we find somthing that looks like this <!ELEMENT body %Block;> <!ATTLIST body %attrs; onload %Script; #IMPLIED onunload %Script; #IMPLIED > Code (markup): The first line reads as "<!ELEMENT element_name valid_child_nodes>", we can see the example is defining the <body> element. Now, what does "%Block;" mean ? If we search for "% Block" in using CTRL+F or whatever else your editor uses, we find outselves looking at this. <!ENTITY % Block "(%block; | form | %misc;)*"> Code (markup): Here's where the Regular Expressions come in. (...) is a sub pattern, "|" means "or" and "*" means "zero or more times". In this case that line means "(%block; or form or %misczero or more times". So, we now know <form> is a valid child element of <body> in this DOCTYPE. To find out the others, we just lookup the entities for "%block;" (note the different case b~B) and "%misc;" using the same method we used to get where we are now, buy searching for the entity name after placing a space between the % and the name. "%block;" happens to be defined directly above "%Block;" in this DOCTYPE. There's a couple more "zero or more times" type quantifiers you need to know. "*" means "zero or more times", as you know. In the example, following the sub pattern, it means the sub pattern must match zero or more times. If it was just "form*" it would mean the <body> element could only contain <form> elements zero or more times, nothing else. "+" means "one or more times", same idea as before but this time there must be at least one occurance of the element(s) defined directly to the left of this symbol. "?" means "zero or one time", it doesn't have to be there. It can be there once, but not two, three, or more times. That's all you really need to know for the Regular Expression stuff for now. Now, for that section under the <!ELEMENT definition. <!ATTLIST body %attrs; onload %Script; #IMPLIED onunload %Script; #IMPLIED > Code (markup): That works like a combination of the <!ENTITY and <!ELEMENT definitions. The element name it applies to is on the first line like with the <!ELEMENT definition. The valid attributes for the element are listed on the lines following that as they are in the <!ENTITY definitions. Same deal with "%Script;" and "#IMPLIED". That should be plenty to get you started with reading a DOCTYPE. Once you get the hang of that, learning the difference between "block-level" and "inline" elements like Dan Shulz suggested will be a breeze. There's actually entities named "%block;", and "%Block;" like in the examples & those are "block-level" elements. There's also "%inline;" and "%Inline;" entities. :big-smiley-disabled-grin:
Goddamn I've been wondering for the past, I dunno, weeks if regular expressions meant anything to doctypes. Now I just need to wait until more than the * can come into CSS... how many many many times have I wanted to be able to h? or form* (I've started naming my forms "formsomething" so I know which is what in my CSS) bleh. Mostly though I end up googling just ONE element to see it's properties (block or inline, what parents, which children, etc). Because I'm lazy, and 90% of the elements seems to be the same between various doctypes. Still, this is extremely useful. Thx, Joe.
I did search the forum for "table", but didn't bother going to the second page. Sorry about that. I now realize that this question has been asked quite a lot. Good point. I agree that both Google and Yahoo could save some bandwidth, if they stopped using tables! However, I'm not going to create any sites at that scale, so it won't really be any problem. And if I need to seperate the presentation from the content, I can just do an <?php include "presentation-style-tables.php"; /?> Maybe I just don't know CSS enough. But so far, I just don't see anything that make it better that tables. Joebert, thank for a great post. I'm a bit busy right now so. I'll check it out later. It sounds useful ...
I like using divs as the codes looks a lot cleaner and sometimes when I use tables, theres just too much <td> especially when using dreamweaver. So I think divs plus css is better than using tables.