The following is a guest post by Sebastian Ekström (@seb_ekstrom) a web developer from Sweden. I was interested in it because we talk a lot about CSS around here but have never talked about how CSS comes to be. CSS is just a syntax invented by people like you and me to try and solve problems. It’s an extremely complicated thing involving: ease of use, backwards compatibility, browsers ability to implement with satisfactory speed, coverage of use cases, attempting to see the future of what is needed and how things may be used, and more. As we well know, bad choices hurt, and hurt for a long time. That’s why there is a process. Here is Sebastian’s intro to that process. I had Tab Atkins review it and comment prior to publication.
How does a new CSS property get standardized? Who makes the decisions? Why should I care about the standardization process? What’s the deal with airline food? I’ll be covering that, and some more in this post.
Background
The standardization of CSS is managed by W3C Cascading Style Sheets Working Group (CSSWG), which of today consists of 98 members from browser vendors, university, larger companies and independent CSS experts. This group is organized by Peter Linss and Daniel Glazman, who coordinates CSSWG’s meetings and makes sure that the discussions are relevant and moved forward.
The communication and decision making in the CSSWG comes in different ways. Discussions about specifications are continuous over email and phone conferences, and they have yearly meet ups where they see each other in person.
The decision making is based on consensus. Discussions are made until all members have agreed on the subject, after that a final decision is made on the creation of a new specification.
The standardization process generally consists of six stages, where two are transition stages.
1. Editor’s Draft (ED)
Example: Colors (Level 4)
This is the starting stage of a specification. An idea of a new CSS property or selector are being specified, and is being worked on internally by the CSSWG. This is a stage where a lot can happen to a specification. And if the group agrees that this should be officially published, it continues to the next step.
Editor’s note: CSS modules come in different levels. “CSS3” is barely a thing, it’s just “everything after 2.1.” CSS4 isn’t a thing. From here out, modules will have levels and will move through this process independently of other modules.
2. Working Draft (WD)
Example: Animations
Followed by the Editor’s Draft comes the Working Draft, the design stage of a standardization. The group works iteratively with a specification with feedback from both internal and external parts. The result of this stage is either that the specification is rejected completely, due to technical difficulties or other issues that might have risen. If the specification on the other hand passes this stage, it’s published as a First Public Working Draft (FPWD). A rough version of the specification that indicates that the CSSWG will continue to work on it.
3. Transition – Last Call Working Draft (LCWD)
Example: Text
This is the first transition stage. When the specification is considered ready to go from Working Draft to the next stage, a deadline is set for any last possible feedback for minor changes.
Editor’s note: Tab tells me these transition phases (also see #5) are rather insignificant. The major important phases are ED, WD, and CR.
4. Candidate Recommendation (CR)
Example: Backgrounds and borders and Flexbox
This is where the specification is thoroughly tested, by both the CSSWG and browser vendors (Chrome, Safari, Firefox, Opera, etc.) that chooses to implement this specification. Which most often happens when it’s reached this stage. To continue to the next stage, the CSSWG has to demonstrate two correct implementations of the specification.
5. Transition – Proposed Recommendations (PR)
Example: No module currently in PR
When this stage is reached, the W3C Advisory Committee, who works as a W3C global advisory group, decides whether or not the specification should continue to the last stage.
6. Recommendation (REC)
Example: Color.
If a specification reaches this step, it’s considered complete and ready for browser vendors to implement. The W3C and CSSWG no longer works actively with the specification, and are only doing small maintenance work on it if needed.
Editor’s note: Turns out Recommendation status is more of a graveyard than an ideal state. Browsers are implementing at the Candidate Recommendation stage. Tab Atkins clarifies:
By the time a spec reaches REC, it’s actually dead, not stable. Errors have probably accumulated, which haven’t been fixed because updating RECs is a pain in the ass. New versions of the spec might already be in development, the feature itself might have died, etc.
Why should I care?
Why should you care about the standardization process? I think it’s important to know how a specification can behave in their different stages, and what the consequences can be if you use them too early.
We all remember how the gradient property messed things up when a syntax couldn’t be agreed upon. This was the old syntax from the beginning of 2011, when the specification was in its Working Draft:
background-image: -webkit-gradient(linear, 0 100%, 0 0, from(fuchsia), to(yellow));See the Pen iKmjh by sebastianekstrom (@sebastianekstrom) on CodePen
Later on, when the specification hit Candidate Recommendation the syntax was changed to this:
background-image: -webkit-linear-gradient(fuchsia, yellow);
background-image: linear-gradient(fuchsia, yellow);Which produced a completely different result:
See the Pen gJCzd by sebastianekstrom (@sebastianekstrom) on CodePen
Editor’s note: Stability of a feature isn’t actually all that tied to what stage in the standardization process it is in. Tab Atkins had this to say:
Stability has basically no relation to the process stages, at least up through Candidate Recommendation. A feature is stable when it’s shipped and can’t be changed anymore due to backward compatibility. This might happen to a feature in an Editor’s Draft spec. And some Candidate Recommendation’s have unimplemented (and thus unstable) features. That’s the correct gauge of stability, not the stage it’s at in the W3C process.
Final words
So if you are going to use some new bleeding edge property, check what stage that specification is in. Working Draft? I would approach it with caution. Candidate Recommendation? I say go for it, but keep an eye on for changes.
When in doubt, I would recommend asking yourself this question: “Will things fall apart if this doesn’t work?”
Will functionality or availability be harmed if an implemented feature stops working because of syntax changes? It’s not the end of the world if your buttons to stop having rounded corners. But if your new site is completely based on a new layout system, and the syntax changes, then you’re in for some trouble.
Is there an easy place to view properties, what transitional-state they’re in and any important changes to those in-use?
A table would be great but I don’t think it’ll be that easy. (:
This is kind of what you’re looking for. Other than that, you have to look in the properties specification.
I find this site pretty useful.
Your text to link here…
Gives the status of CSS3, HTML5, SVG and more. Lists if they are Release Candidates, Working Drafts and also has tables of support in the main desktop and mobile browsers.
I wonder why so called “CSS Snapshot”, which is labeled as “Latest stable CSS” and contains something like formal definition of CSS, has only the “Group Note” status (AFAIK this means that the document is not just a dead spec, but not a spec at all) and hasn’t been updated for almost 3 years. I suppose it would be nice if this document reflected the actual state of CSS at any time, having easily accessible lists of implementation-ready and production-ready specs in one place, and getting updated continously by a “living standard” model.
From where can we get to know about the new css properties that are on working draft stage?
Hi Chris, You brought us to the genesis ( beginning of things). It is quite essential to know these facts, as you have said “Will things fall apart if this doesn’t work?” I’m just curious to know how the whole web will be in the next 10 years. Am I permitted to post this on my blog consulting site for my readers and learners to understand the origin?
Can you repost this in full on your own site? You can, but that’s kinda rude. Can you link to it from your blog? Sure, and you don’t really need my permission for that. I also removed the double links you had in your comment for “blog consultant site”. That’s also comes across as kinda rude and SEO-spammy. Just a few tips there for your blog consulting business.
I didn’t see it anywhere in the article, but it should be noted that the CCSWG has a public mailing list that anyone can subscribe to* (and participate, if they wish).
* It’s totally worth it, IMO; but take note that it’s in the neighborhood of 600 – 1,000 emails per month.
Tab’s statement that a Recommendation is “Dead” is a perspective. It is indeed difficult to change a Recommendation, but that’s the idea. It becomes a stable reference, unlike a Candidate Recommendation that may shift under a developer’s feet, when someone shows that something in it doesn’t work in practice.
Specifically, as well as the work of identifying what needs to be changed, there need to be a couple of drafts published, and preparing a draft can take at least an hour. Usually the group will also need to convince the W3C director that the Recommendation needs to be edited, which often takes a meeting of 30-60 minutes.
But the normal practice is to produce a next version, which will include more features. And if it changes something in a way that invalidates an existing Recommendation, it is good practice to produce an edited version of that Recommendation at the same time.
(If you are really fascinated by the W3C Process note that they are looking at changing the details somewhat, and the discussion is open to the general public to both read and actively participate, via the W3Process Community Group)
Thanks this is pretty useful, it was quite interesting to see the who makes the decisions too. Good idea to check what status the newer features are in before implementing any, I’ll be doing that from now on! :)