‘CSS X’

CSS development started some 25 years ago. Originally the goal was to provide some good but simple typography for a single column of text with the occasional image. But the technology proved popular, and flexible enough that the scope could be made much wider. And since then the work of adding new capabilities hasn’t stopped. CSS now handles multiple columns, vertical text, diagonal text, layout for graphical user interfaces, image operations, animations, some key and mouse interaction, and more.

Since 1996, when CSS was first standardized, many operating systems have had ten or more new versions, browsers have gone through several dozen versions. Many browsers completely disappeared and several new ones were created. CSS has grown, too, but it is still called CSS.

According to some people, that is a problem, in particular a marketing problem, and in more than one way. It is a problem for W3C, because there is never a big event to announce that ‘CSS X’ has arrived with all its great new features. Instead, new possibilities get added little by little at irregular intervals, unnoticed by many. It is a problem also for Web developers, many of whom do not have the time or the interest to follow W3C or the various software makers to see what is new in CSS. They may only become aware of new features by accident later. And it is a problem for Web developers who want to market themselves: What do they put in their CV? If they write ‘CSS expertise’ it could equally well mean CSS as it was ten years ago as the current state.

Before we see if there is a solution and if so, whose responsibility it is, let’s first look why CSS is the way it is.

The original goal for CSS was to create a technology that provided good typography for simple documents.

As I said above, the original goal for CSS around 1995 was to create a technology that provided good typography for simple documents on the Web, such as those in HTML. As simple as it was, compared to traditional document layout, it proved a challenge for the early web browsers. For that reason, a small subset was standardized first, in 1996, under the name ‘level 1’. The full CSS followed two years later, as ‘level 2’.

CSS level 2 actually still fell short of what was originally envisaged, due mostly to browsers having more difficulty than expected. (The main ones at first didn’t even have data structures to store a document tree. And they had bugs that they couldn’t fix, for fear of breaking important web sites.) But CSS nevertheless proved popular and people asked for more features. It turned out that the syntax and the system of cascading and inheritance could support more typographic capabilities without too many problems.

But the specification for CSS level 2 was already quite a big document, spread out over more than two dozen HTML files. And although some of the requested new features were easy, some looked like they might require some study. For those reasons, the working group decided to split up CSS and turn it into a family of smaller specifications, called ‘modules’. Each module contains a small set of related properties or other features (selectors, @-rules, etc.) and depends as little as possible on other modules. That means it can be developed at its own speed. Also, each module is small enough that it fits in a single HTML file, making editing and publishing much easier.

The full set of modules of CSS now includes everything from modules that are still level 1 to modules that are already level 5.

CSS was thus split up in modules such as ‘Selectors’, ‘Backgrounds and borders’, ‘Fonts’, etc. And over time new modules were added, such as ‘Writing modes’, ‘Grid’ and ‘Transformations’. Modules that contained features already published in level 2 in 1998 were called ‘level 3’, to indicate that they included level 2 and more. Modules with only new features got the name ‘level 1’, to indicate they were not a superset of anything. Over time, some modules got standardized, then expanded again with newly requested features, standardized again, etc., so that the full set of modules of CSS, both standardized and under development, now includes everything from modules that are still level 1 to modules that are already level 5.

In other words, CSS as a whole doesn’t have levels anymore. It is instead a family of specifications (the modules), which individually acquire new levels as new features are added to them. At any moment in time, current CSS is defined as the set of all modules that are stable. E.g., last December, the module ‘CSS Writing Modes Level 3’ was published as a W3C Recommendation. At that moment, CSS implicitly changed: It was no longer defined by the previously published Candidate Recommendation of that module, but by the new Recommendation. But there was no new publication of any document called ‘CSS’.

This works well for the working group, which can publish new capabilities for CSS whenever they are ready, without waiting for other, unrelated features to be ready, too. It works for the implementers as well, as long as they know what modules make up CSS and which of them are stable. (The working group provides that information, notably in the form of the CSS snapshot, which it updates every other year or so. W3C also has a web page showing the working group’s current work.)

The best known sources of implementation status are probably MDN and Can I Use.

But does it work for the people who use CSS to write style sheets? The working group decided long ago that its task was to provide precise and useful information for implementers, i.e., makers of browsers and other software that deals with CSS. It wouldn’t have enough resources anyway to provide the same level of information to users. In particular, it doesn’t study how widely some part of CSS is implemented and thus for what purposes it can be used.

The working group does look at implementations, but only in so far as needed to check that a specification is implementable. Typically, if two software makers succeed in implementing a feature, that is proof enough that the feature is viable. Often there are more than two implementations, but sometimes it takes time before other software makers get round to implementing the feature. The CSS working group, like most working groups in CSS, does not actively follow the state of implementations after a specification has been published. There are, luckily, other people who do. The best known sources of implementation status are probably MDN and Can I Use, at least for the status in several well-known browsers. For other software, the best source is usually the software’s own documentation.

‘A tremendous number of books, courses, and conferences were dedicated to CSS3.’

Back to the question of defining CSS versions for the purpose of developers: How would it be defined in a useful way? How often should a new version be defined? And who could define it?

CSS is used for many things. The useful set of properties is different for a mobile app than for a web page. And if you are a publisher laying out books with CSS, the interesting properties are different again. Maybe there should be different series of CSS versions for different purposes.

To be useful, a version of CSS should be reasonably supported in implementations at the time it is defined, so that it makes sense for web developers to start learning that version. Which in turn is an incentive for other software makers to also implement it. What is the criterion for a ‘reasonable level of support’?

People have argued that there should be new versions with a certain frequency. But not too often, because people don’t have time to read too many announcements. And people will want to write books about the new version, or develop talks and courses about it, which takes time. As Jen Simmons wrote, quoting Chris Coyier, ‘a tremendous number of books, courses, and conferences were dedicated to CSS3’ even though there is no definition of what CSS3 is. The working group certainly never defined it.

And new versions should not be spaced too far apart either, because it would be a waste if interesting new features weren’t picked up for several years.

And who could define a CSS version? The CSS working group doesn’t seem to feel it has time for it. Fantasai suggested that the working group could just act as the publisher. Maybe there can be a committee with members nominated by various organizations of web developers. They would meet every once in a while to decide if there should be a new version and if so what it contains. Or maybe the CSS4 Community Group that formed itself last month finds a way to become such a committee.

According to Peter-Paul Koch, a precise definition of ‘CSS X’ isn’t even needed. Every three years of so, some people should pick a couple of interesting new modules that were added in that period and start writing about them, under the heading ‘CSS 4’, then ‘CSS 5’, etc. ‘CSS X’ is defined as those two or so modules, plus whatever was in the previous version and a loosely defined set of other modules.

Additional reading:

from Hacker News https://ift.tt/2INhmNq