Bert Bos | CSS future – Beijing 2015

CSS Future

Cascading Style Sheets

The state of CSS standardization in 2015

Bert Bos (W3C) <bert@w3.org>

Beijing, China
10 January 2015

Standardization process

[image: the path from member-only
    draft to public Recommendation represented as a snakes-and-ladders

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.)

Why levels? (1/3)

Given that

Why levels? (2/3)

… we need a language that is

Why levels? (3/3)

… Thus, we try to

(Exceptions: the spec had an error, or a feature was never correctly implemented.)

“Level” tries to express this: level n+1 is a superset of level n

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.


1 spec. 1 spec. ~ 60 modules
5K lines 54K lines 201K lines
level 1 level 2 Selectors level 3 Selectors level 4
Colors level 3
Fonts level 3
Lists Level 3
Tables level 3
Media Queries level 3 Media Queries level 4
Positioning level 3
Paged Media Level 3
Transforms level 1
Animations level 1
Ruby Layout Level 1

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.

Online roadmap

(screendump of the “Current work” page)

For an overview of CSS specifications and their status, see “CSS current work & how to participate” (a.k.a., the “Roadmap”)

Where does the CSS WG get ideas?

Source How can you help?
The companies the members work for Your company must join W3C before it can join the WG
Other groups in W3C (DPub, SVG, HTML, WebApps, I18N, I18N TFs, WAI…) Ditto
W3C liaisons (IDPF, Unicode, other standards organizations…) Join the WGs of those organizations
<www-style@w3.org> Anybody can join the mailing list
Conferences, workshops, personal communications… Watch W3C agenda; find e-mail addresses on the specs

Note: Nearly everything is in English

Development areas & liaisons

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.

Generally useful modules

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.

Paged media

These slides are also an example of paged rendering…

Paged media – challenges

Footnotes, running headers, mathematics, copy fitting, change bars, changing the visual order, cross-references, alphabetic indexes…

(We want to catch up with XSL)

Photo: a running header with some math

“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.

GUI layout & apps

GUI layout & apps – challenges

Graphics effects

FX task force together with SVG WG

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.

Graphics effects – challenges

Conclusion (1/2)

Even though CSS is over 18 years old…

Conclusion (2/2)

The end



To Lead the Web to its full potential

To Anticipate the Trends

To Increase your company value

Join W3C


or contact: An Qi Li

Bert Bos <bert@w3.org>
GPG fingerprint: 7744 0204 52A5 14D9 147D
2A13 2D7A E420 184B 5BA4