CSS is both a standard and a technology in development. Knowing which part of CSS is finished and which part you cannot use yet is a challenge. It has been like that since many years and is likely to stay that way for a couple more: the standard part is slowly growing, the part still in development has been growing as well, but should eventually diminish.
This article explains how the CSS working group itself keeps track. It may be useful next time you see a new publication on the W3C site and wonder how close to a standard it is.
For software makers, there is an easy way to know what parts of CSS should be implemented and what parts not yet. Since 2007, the working group publishes so called snapshots, which explain exactly that. Much of the text of this article is in fact taken from the 2010 snapshot.
So far there have been five snapshots, the currently latest is called CSS Snapshot 2018. The intention is that new ones appear every one or two years, depending on how much of CSS becomes stable in that period. The most recent snapshot can always be found at this URL:
Implementers interested in the experimental features, and everybody who wants to help develop CSS, may also find the CSS current work page useful: it shows the current status and a short description of all existing parts of CSS.
For users of CSS, the situation is unfortunately less clear. Even if some part of CSS becomes a standard (i.e., a W3C Recommendation), it only means that that part has been correctly implemented in a certain number of implementations. It does not mean that all implementations of CSS support it. Trial and error, and fallback solutions, remain necessary.
Originally, in 1994–1995, the plan was to create a single CSS specification, with comparable size but slightly different features than the current level 2 (with template layout, run-in headers, columns, downloadable fonts and running headers and footers, but without absolute positioning). It would be a ‘temporary’ style sheet language, good enough to avoid things like FONT tags and misuse of HTML tables for maybe up to ten years. The experience would help create a better, more powerful successor.
Things didn't work out that way. It quickly became clear that the browser makers at the time were not skilled enough yet in typography and structured text, and CSS had to be made a lot simpler if we wanted it to be implemented. That led to the split in level 1 and level 2. Later we also discovered that people didn't want to replace CSS and rather wanted to make it bigger.
The CSS working group chose to adopt a modular approach for CSS beyond level 2, where each module defines a part of CSS, rather than to write a single monolithic specification. This breaks the specification into more manageable chunks and allows more immediate, incremental improvement to CSS.
A separate document, the CSS snapshot, defines the current scope and state of CSS. It includes only modules that the working group considers stable and for which there is enough implementation experience to be sure of that stability.
Specifications listed in the snapshot are not completely frozen, though. They include W3C Candidate Recommendations (see below). But even the listed W3C Recommendations (standards) may still receive errata.
Module and snapshot are two kinds of documents. The CSS working group uses those names as explained above, but other working groups may use them in different ways. On the other hand, to indicate the stability of each document, W3C has a vocabulary that all working groups share:
In the CSS WG's experience, the recommendation track is not linear. The experience is that many specifications enter CR twice, because implementation testing often uncovers significant problems in the specification and thus pushes it back to working draft. As a result, although the CSS WG has a clear idea of the stability of the CSS specifications, it is difficult for someone outside the working group to come to that same understanding based on a specification's official status. For that reason, a CSS Snapshot does not necessarily include all CR documents: the working group may already know that a certain CR will have to be revised.
Cascading Style Sheets does not have versions in the traditional sense; instead it has levels. Each level of CSS builds on the previous, refining definitions and adding features. The feature set of each higher level is a superset of any lower level, and the behavior allowed for a given feature in a higher level is a subset of that allowed in the lower levels. A user agent conforming to a higher level of CSS is thus also conformant to all lower levels.
Last updated Wed 06 Jan 2021 05:41:35 AM UTC