When you don't really have a lot to
unlearn with respect to tables, you're in a better place than those who do.
Rule 1: You don't need to memorize a pile of element names and specs.
In practice you'll be working with divs, headings, paragraphs, and lists with respect to layout, along with the occasional image.
Rule 2: Chances are that if you're doing it right, you'll be using a lot of CSS background images instead of inline images.
Images that stand for content can be said (if you're a True Believer like myself) to belong in inline image elements, while the rest should be published via CSS rules. YMMV.
Rule 3: You'll need to comprehend the different between inline, block, and list-item elements.
This information is most easily found at
http://www.w3.org/TR/html401 - where the section for each element is prefaced with its DTD block. One of the data attached to each element name will be its type - %block, %inline, or %flow most of the time. There are others as well.
Rule 4: In order to make IE6 play nicely, you'll find yourself assigning height and/or width values to elements that don't actually need them.
This is due to peculiarities in the IE rendering engine that even seasoned professionals have a difficult time at understanding.
Rule 5: Use containing elements if and only if you need to... which will be often.
The fewer elements you use, the easier it will be to manage your work product.
Rule 6: The cascade works for some CSS properties, but not others.
As a rule text properties will cascade/inherit, but layout/box properties will not.
Rule 7: Well-tuned descendant selectors are your best friend when you write a stylesheet.
I'll let Google explain this one.
Rule 8: Putting an id on the body of each document is a Good Idea when you're starting out.
Whether the ids in question is section-specific or actually page-specific, including these id's will give you a solid baseline for those occasions on which you need to work with descendant selectors.
Rule 9: Bear in mind that done well, leverage of CSS allows you to put the components of a site into their own baskets.
Presentation goes in one basket (via link elements), behavior in another (via script elements that request external files), structure in a third (via well-considered templates), and content in the ultimate (your actual documents/pages/DB-records).
Rule 10: The most important goal of avoiding tables is to ensure that your document sans styling reads coherently.
If you can achieve the goal of coherence while using tables for layout and decide to take that approach, that makes you a pragmatist - not a criminal.
Adjunct to this is that impaired users are fairly split down the middle with respect to preference for site nav bits being at the top of the page or the bottom.
Another benefit to avoiding tables is that your work is more likely to be readable in narrow viewports (read: mobiles) but given the Balkanized state of display support in the mobile space, this becomes a secondary concern for a lot of folks.
The best secondary benefit to avoiding tables is that you can set aside a well-rounded print stylesheet for your entire site that will be comparatively easy to write and maintain.
In closing, I'll toot my own horn and point out that there are a few goodies of mine over at
http://www.henick.net/vignettes/ which, while aimed at the experienced reader, manage to point (on the by and by) to some sites you might find worth visiting (if you haven't already).
