So you want to learn Cascading Style Sheets (CSS), eh? Well I can't teach it to you in one blog post - there are entirely libraries devoted to the subject for a reason. I'm sure you have crossed many of sites that try to teach CSS thoroughly as well - I have found that most of them come up short in one way or another.
So rather than pointing you to a few obscure sites, or praising one book or another (which get outdated faster than they can be printed, unfortunately, as I do love books), I would like to point you to some of the more official resources for learning CSS. With these sites alone, you CAN become a master at CSS - theres not to many website you can say that about.
Where to start?
How about the OFFICIAL W3 Consortium? These are the folks that define the specifications as they are intended to be interpreted. As of the date of this article, CSS 2.1 is the current specification and can be found here: http://www.w3.org/TR/CSS21/.
If you go to W3's official website, you will notice that future versions of CSS are in the works. Some of those specifications are already being implemented in current browsers, however, anything specified in CSS 2.1 should be currently valid.
W3 also provides a very comprehensive list of other websites with CSS tutorials. Naturally, everyone will have a preference, so it's best to browse a few and see which ones suite your style.
Where to next?
As we all know, not every specifications by W3 is followed consistantly accross browsers. You can find the specifications for each browser though. Here are the top three:
There are many 3rd party websites that try to maintain a list of browser support for CSS attributes. One such site is Quirksmode.org. Click here to see thier current browser cross-check list.
If that site doesn't suit you, I would encourage you to search around for other sites that list cross-browser compatibility. There are many out there.
What about an API (application programing interface), such as Dreamweaver?
I'm not a big fan of Dreamweaver. Truthfully, I just don't find it that usefull over coding from scratch. I ended up spending a lot of time learning how to do it 'thier way', as opposed to learning just how to do it right - and when I needed to adjust things, it became in issue. I would advise you get yourself a good text editor (jedit, notepadd++, or my favorite, E-Text editor). These aren't just boring old notepad's that ships with windows, these are highly integrated coding machines. What's better, is that as you move onto integrating Ruby on Rails, PHP, Python, or any other web language, they do a great job of syntax highlighting and you will be well into the flow of things if you start with them early. If you really want to get fancy, go to eclipse.org and download their open source IDE which has a plugin for almost any language under the sun.
Once you have some knowledge of the syntax and how to postion elements accordingly, there are a couple of habits that may help you 'think' about your css.
First, I want to answer a question that always bothers me: what's the difference between class selectors ( .myClassSelector ) vs. id selectors ( #myIDSelector)? You have undoubtably seen them used in what appears to be random selection, mixed and matched together, and used all over the place. Why, and when, should you use them? Know this: id's can only be used ONCE per html page, classes can be used multiple times in the page. So if you are coding a PHP page, with a for loop that output blocks of similar information, using a <div id="myformat"> will either be completely ignored, or worse - executed numerous times in a very odd fashion (such as a top table border appearing 3x PRIOR to any of the table content) . You need to use the class.
Why not just use classes all the time? Mainly, because the id= syntax is 3 characters shorter than class=, and it looks pretty sprinkled throughout your code. Ok, really, you never need to use an ID, it provides no functional benifit. However, for code legibility, it is often used for element positioning, especially in layouts since each section should only be positioned exactly once on a page. Occassionaly, I also see the id and class used in combination, where the id has the same name as the html document, and the class is the format. (such as #index.myHeaderFormat{} ) This sometimes makes the CSS more legible since the reader can clearly see what html page that style was designed for.
The next suggesion I have is to define your classes (or id's) in blocks together prior to inserting a single line of formating. For example, I will often start with something that looks like this:
.data_table dl {}
.data_table dt {}
.data_table dd {}
.data_table a:link {}
.data_table a:visited {}
.data_table a:hover {}
.data_table a:active {}
I do this for two reasons. One, it simply helps me think of how many elements I need code and is easier to read as a group without added lines. Two, sometimes the order of your css definitions is important, as in the example above - a:link, a:visited, a:hover, and a:active - must appear exactly in that heirarchial order, else it won't work.