Update stage definitions

[jonathantneal]

The goal of this project is to reflect the real-life stability of new CSS features. This is intended to be helpful to developers who seek to accomplish real things with modern and emerging technologies. This simplified overview should improve communication between developers, authors, and implementors, thus improving the creation of standards, testing, feedback, and new use cases.

However, grouping CSS features into simple, digestible stages is actually very hard. One reason for this is because the maturity of a specification does not necessarily align with either its draft label or the maturity of its implementations. Here are the current staging criteria and definitions.

To better address this particular issue, I would like to revise the criteria and description of all stages. With criteria revisions suggested by @fantasai, and assistance understanding the TC39 process from @hzoo, I would like to revise the criteria and definitions for each stage to be as follows:

Stage 0: Aspirational

An Unofficial Draft or Editor’s Draft championed by a W3C Member. It is highly unstable and subject to change. Stage 0 features are open to ideas and discussion, but may not be considered serious.

Stage 1: Experimental

An Editor’s Draft or early Working Draft championed by a W3C Working Group. It is highly unstable and subject to change. Stage 1 features are recognized as a real problem, but they may not be tied to any particular solution.

Stage 2: Allowable

A Working Draft championed by a W3C Working Group. It should be considered incomplete, unstable, and subject to change. Stage 2 features are tied to a particular way of solving a problem.

Stage 3: Embraced

A Candidate Recommendation championed by a W3C Working Group with implementations by at least 2 recognized browser vendors, possibly behind a flag. It should be considered stable and subject to minor change. Stage 3 features will likely become a standard.

Stage 4: Standardized

A Candidate Recommendation or Recommendation championed by a W3C Working Group and implemented by all recognized browser vendors. Stage 4 features are considered a standard.

@fantasai, do you feel this would better reflect the stability of CSS features? @hzoo, do you feel this still captures the spirit of TC39 stages? If not, how would you recommend I improve them?

By refining these definitions, I do hope this staging process could be formally adopted by the CSSWG.

[fantasai]

I'd say WDs are generally tied to a particular way of solving a problem, but are likely to morph significantly over time in response to feedback. E.g. Grid was recognizably Grid in the earliest stages--the general approach didn't change, but a lot of things about it did change. I can't speak to TC39 stages. I also don't know what problem you're trying to solve, and why it's tied to TC39's stages specifically.

[SelenIT]

Maybe features explicitly cleared by the CSS Working Group for broad release prior to the spec reaching Candidate Recommendation could also be considered Stage 4?