Many frameworks seek to abstract away from HTML (custom tags, JSFs component system) in an effort to make dealing with that particular kettle of fish easier.
Is there an
If by some chance you happen to be using Ruby, there's Sass. It supports hierarchical selectors (using indentation to establish hierarchies), among other things, which makes life easier to an extend from a syntactical perspective (you repeat yourself a lot less).
I am certainly with you, though. While I would consider myself a small-time CSS expert, I think it would be nice if there were tools for CSS like there are with Javascript (Prototype, JQuery, etc.). You tell the tool what you want, and it handles the browser inconsistencies behind-the-scenes. That would be ideal, methinks.
You don’t need an abstraction away from CSS—you need to realize that CSS itself in an abstraction. CSS isn’t about putting pixels just so on the screen. Instead, it’s about writing a system of rules that help the browser make those decisions for you. This is necessary, because at the time you write CSS, you don’t know the content the browser will be applying it to; neither do you know the environment where the browser will be doing it.
Mastering this takes time. You can’t pick up up CSS in a weekend and be good to go. It’s a bit deceiving, because the language has such a low barrier of entry, but the waters run deep. Here is just a few of the topics you should seek to master to be proficient in CSS:
You don't need to know this all up front, but you should continue pushing forward. Just as with other languages and programming in general, you need to continually seek to learn more and master the craft. CSS is a fundamental part of web development, and more developers need to treat it with the same respect they afford other languages.
Sorry to say that guys, but all of you missed the point.
The word abstraction is the key. Say you and Sally are making a website. You are styling forms while she makes the corners round. Both you and she have defined a handful of selectors.
What if, unknowingly, you picked class names that clash with the ones of Sally? You see, you can't "hide" (abstract out) the details when you work in CSS. That's why you can't fix a bug in IE then create a self-contained solution that others can use as-is, much like you call procedures in a programming language only caring about pre- and postconditions and not thinking of how it works on the inside. You just think of what you want to accomplish.
This is the biggest problem with the web: it completely lacks abstraction mechanisms! Most of you will exclaim, "It's unnecessary; you stop smoking crack!"
You will instead do the job of say, fixing layout bugs or making round corners or debating on the "best" markup for this or that case over and over again. You will find a site that explains the solution, then copy-paste the answer then adapt it to your specific case without even thinking what the hell are you doing! Yes, that's what you will do.
End of the rant.
You are thinking about this correctly though, you're probably still going to need to understand the different browser implementations of CSS. This is just understanding the environment your application lives in.
To clarify: this isn't about understanding CSS. If you know the language well, you've still got to handle the redundancy, duplication and lack of control structures in the language.
Ive been writing CSS solidly for more than 10 years and I've come to the conclusion that while the language is powerful and effective, implementing CSS sucks. So I use an abstraction layer like Sass or Less or xCSS to interface to the language. These tools use a syntax similar to CSS so you're solving the problem in the problem's domain. Using something like PHP to write CSS works but is not the best approach.
By hiding the problems in the language through an abstraction layer, you can deliver a better product that will maintain its integrity throughout the full life cycle of your project. Writing CSS by hand accelerates software rot unless you're providing solid documentation which most CSS coders aren't. If you're writing a well documented CSS framework, you probably wouldn't write it by hand anyway. It's just not efficient.
Another problem with CSS is due to it's lack of support for nesting block declarations. This encourages coders to build a flat, global set of classes and handle the name collisions with a naming convention. We all know globals are evil but why do we write CSS in such a way? Wouldn't it be better to give your classes a context instead of exposing them to the whole document model? And your naming convention may work but it's just another task you must master to get the language written.
I encourage those of you who pride yourselves on writing good CSS to start applying some of the best practices from programming to your markup. Using an abtraction layer doesn't mean you lack the skill to write good CSS, it means you've limited your exposure to the weaknesses of the language.
See, this is the problem with SO-- every answer so far has made a valid point and should be considered the final answer. Let me try to sum up:
I think a combination of all these certainly solves a large sum of problems (although to be fair deeply learning CSS is not an option for everyone; some people just don't use it enough to justify the time).
There are some problems none of the above points cover (certain types of calculated fields would require writing a JS library for, me thinks) but it's certainly a good start.
I believe the common errors beginners have with CSS are to do with specificity. If you're styling the a tag, are you sure you really want to be styling every single one in the document or a certain "class" of a tags?
I usually start out being very specific with my CSS selectors and generalize them when I see fit.
Here's a humerours article on the subject, but also informational: Specificity Wars