‘CSS X’ | W3C Blog

nc efi placeholder

CSS logo1sCSS 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 litle 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.

CSS color tree3t 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

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

‘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
, 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:

Source link

Leave A Reply