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 CSS 2.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 CSS 2.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.
Last updated Fri 01 Apr 2022 03:21:29 PM UTC