You don't need to be a programmer or a CS major to understand the CSS specifications. You don't need to be over 18 or have a Bachelor's degree. You just need to be very pedantic, very persistent, and very thorough.
A specification is not a manual. There is no excuse for badly written prose and please complain if you find some. But specs do target a specific audience.
J. David Eisenberg has written a useful How to Read W3C Specs for web designers. If reading technical specifications isn't part of your daily fare, I recommend starting with that.
Also, if you are totally clueless about CSS, I recommend you first learn
what it is and how to use it. For a very brief tutorial, you can start with
the Introduction to
CSS2.1. For a fuller, friendlier
introduction, pick up a learning CSS book that focuses on CSS fundamentals
rather than on design. Play with CSS in a text editor. Design a few mock
homepages. Get introduced to selector specificity and margin collapsing.
Add * { border: 1px dashed gray; }
to a web page so you can
see the box model. Having an idea of where this is all headed will
help you fit together all the dry technicalities in the specifications.
Being able to understand the CSS specifications requires understanding the context, vocabulary, and fundamental concepts that the specifications are built out of. If you want to really understand the specs, you need to really understand the specification sections listed below:
Some CSS specs, such as CSS2.1, have errata, corrections made after the spec's publication. When you are interpreting a spec, make sure you check the errata! The specs are still changing as problems come up through testing and implementation. These corrections have not yet been incorporated into the spec text, but they are critical to a correct understanding of the specification. The errata page is linked from the top of the spec.
The best way to gain a deep understanding of the specification is to work with it (the specification, not just the technology). And the best way to do that is to write test cases and explain why they are correct according the spec. Now you can write test cases on your own just for fun, but you'll learn a lot more and help the CSS community (authors, implementors, and spec writers) at the same time if you get involved in a QA project. You can learn and contribute by writing test cases, improving test cases, making variations of test cases, and answering spec questions about test cases for...
If you've perused the specifications and something still doesn't make sense, you can ask on www-style.