This page contains a list of all completed specifications and drafts by the CSS WG. If you want to follow the development of CSS, this is the place to start. You have ideas? Contributions? See ‘If you want to help’ on this page.
A specification is not a manual. There is no excuse for badly written drafts and please complain if you find one. But specs do target a specific audience. See fantasai's Understanding the CSS Specifications.. J. David Eisenberg has written another useful How to read W3C specs. Or you can read about ‘modules,’ ‘levels,’ ‘snapshots’ and the CSS process.
Ordered from most to least stable:
Some related specifications by other Working Groups:
The CSS Snapshot includes an index of standard and stable properties, along with pseudo-classes & pseudo-elements and @-rules.
The CSS WG provides an alphabetical list of all properties & descriptors in editors' drafts.
W3C indicates the maturity of specifications by a status code. The CSS working group uses the following, from least to most stable:
| Abbreviation | Full name |
|---|---|
| FPWD | First Public Working Draft |
| WD | Working Draft |
| CR | Candidate Recommendation |
| CRD | Candidate Recommendation Draft |
| PR | Proposed Recommendation |
| REC | Recommendation |
| SPSD | Superseded Recommendation |
The following code indicates a document that is not intended to become a standard:
| Abbreviation | Full name |
|---|---|
| NOTE | Working Group Note |
The names are defined in section 6 of the W3C process document. A REC is what is normally referred to as a ‘standard.’ W3C encourages everyday use starting from CR.
The informal stability levels used to group the specs are defined in this 2007 description of CSS stability levels.
Raise issues via GitHub. (You will need to create an account on GitHub first.) Github contains copies of the editors' drafts of the CSS specifications and ‘Houdini’ APIs.
The contributor guidelines explain in more detail what role GitHub issues play in the development of CSS specifications.
If you are raising issues on a specific CSS module, please prefix the title of your issue with the appropriate spec code (given in the ‘Status of this document’ section) in brackets, e.g. ‘[css3-flexbox] error in margin calculations’. This will help the editors find and track your comments.
If you work for a W3C member organization, you can also join the CSS working group and come to its meetings. To participate, you need to commit to (on average) 1 day per week. Contact Chris Lilley and your organization's W3C AC representative. The group's minutes are public and posted on the CSS WG blog.
There are many ways to keep up to date with new
publications by the CSS WG. The ‘What's new?’
section above shows the most recent drafts and it also has an Atom feed.
Publications are announced on the CSS WG's
blog and its
Atom
feed, and the group's
Mastodon account. First drafts from all W3C working
groups appear on the public-review-announce mailing list and its RSS feed. The latest
publications from all W3C working groups are at the top of the Technical Reports page,
which also has an
The archived mailing list www-style@w3.org has the agenda and the minutes of the meetings of the working group. You can subscribe yourself. title="New W3C publications" > RSS feed.
The CSS working group spends a lot of time on developing the CSS test suites along with the CSS specifications. By providing a test suite for each module as soon as the module is published, CSS implementations conform to the specification much earlier; also people have an easier time understanding the formal text of the spec.
Raising issues via GitHub is preferred: see the Web-platform tests repository.
The Bikeshed source mark-up of the specifications follows certain conventions (which is used for automatic processing).