Bert Bos | CSS future – Beijing 2015
If you're an implementer, don't try to implement “CSS level 3” or “CSS level 4”! To get an idea of what is ready for implementation, look at the snapshots we publish every few years. Or just look at what specifications have the status CR or REC. And don't be surprised if some modules called “level 4” are ready for implementation, while others called “level 3” or even “level 1” are not.
After we finished level 2, people didn't want to stop. We paused for a bit, to let implementations catch up, but most people wanted to extend CSS and add a level 3.
XSL had been started in 1998, but people didn't see it as a replacement for CSS. It was, and still is, more powerful than CSS in many respects, but also lacked some aspects of CSS: it was much harder to use for people who weren't programmers and it wasn't suitable for WYSIWYG editing.
But such a level 3 would be very big, and we realized that it had easy parts (that could be finished quickly), hard parts (that would probably need a long time to study) and even parts that we didn't know yet. And so we decided that it would not be a single spec, but several small ones.
As we progressed, we found we needed to split some modules even further, and occasionally we also found it was easier to merge two modules into one (e.g., backgrounds with borders, 2D transforms with 3D transforms).
And we found that people discovered they needed new features in modules that were already finished or almost finished, and so we added an additional level (level 4) for some modules.
Note the numbering “level 1” of some modules: Those are modules that only contain features that were not present at all in the 1996 and 1998 specifications.
But we're not consistent in using “level 1” for that. The number isn't that important. The only hard rule is that a module with a higher level includes everything from the same module with a lower level.
CSS is a complex technology and you cannot really separate its features into different areas of application. Most can be used in different ways. And the separation into modules is mostly due to short-term considerations (available editing resources, available test suites, technical difficulties with features).
But we can see some structure in the demands we get from users, and they fall roughly into two large groups: typography-related, with a focus especially on paginated rendering (books, e-books); and GUI-related, especially for HTML5-based applications.
Within those groups, there are people who are more interested in graphics effects, in interaction, or in typography.
Some modules are even less focused on particular types of applications than others. E.g., the selectors, media queries, cascading and inheritance, values and units and conditional rules do not directly influence any rendering, but are generally useful, no matter what the application of CSS.
“Requirements for Latin Text Layout and Pagination” (or “latinreq” for short) contains a list of requirements in the area of paginated rendering. Despite the name, many of these requirements are not specific to the latn script.
XSL has two parts, called XSLT and XSL-FO. XSLT is for transforming documents and XSL-FO is for formatting them. (CSS doesn't have that kind of transformations, although sometimes you can use JavaScript to change documents via the DOM.) XSLT is still being developed, but W3C failed to find enough resources to form a Working Group to extend XSL-FO, and thus it remains at version 1.
XSL-FO is powerful, but not powerful enough for some printing jobs, and thus people are looking at CSS: CSS is still well behind XSL-FO in many ways, but unlike XSL-FO, it has a very active WG and a large community of people contributing ideas and reviewing specs. And thus it is not unrealistic to expect that CSS can, eventually, overtake XSL-FO.
The modules in this area are made in cooperation with the SVG WG, because we need their expertise, and also because we want implementations of SVG and of CSS to be able to share code. In fact, we created a special task force, the FX task force (“FX” as in “Effects”), with people from the SVG and CSS WGs.
Unlike in the game of snakes and ladders, progress in the W3C standardization process is not the result of chance, but like in the game, you can occasionally skip a step, or be forced to go back.
From the initial idea to a new standard (a.k.a. “W3C Recommendation”), a W3C Working Group goes through a number of steps. If the idea is not yet in the charter of the group, or if there is not yet any suitable group, a charter has to be written which mentions the future new standard and the expected time or resources it will take to make it.
If the charter passes discussions and review with success, the group can start writing. When it has a reasonable text to show, it publishes a Working Draft (WD). It probably has to publish several drafts and go through several rounds of comments before it can ask the W3C Director to publish a Candidate Recommendation (CR).
The Director verifies that there has been sufficient review of the draft (based on a report that the group has to submit with its request) and then releases the CR, and asks the world to try out this candidate for a standard and send feedback.
That feedback occasionally results in a decision to rework the specification and go back a few steps.
Most specifications need a test suite and once there is such a test suite, and there are implementations that pass it, the group can ask for the next step, Proposed Recommendation (PR). Again, it submits a report to the Director detailing the reviews it has received and in this case also the results of the tests.
Sometimes a group is working so well and also has such active implementers that it can skip the CR and ask the Director to go straight from WD to PR.
The Director publishes the PR and asks all W3C members for one last, quick review, lasting no more than about four weeks. If no negative reviews are received, the new specification becomes a W3C Recommendation.
But even after all these rounds of comments and reviews, there are usually still undiscovered errors, and the group continues collecting errata. (Often, that results in an idea for a second version, and the whole process recommences to create that new standard.)
(The drawing is not meant to be a precise representation of the process.)