Abstract

In 1995, I didn't expect CSS to last longer than 10 years. I thought we would learn from the experience and then design a better successor. But nothing better has come up yet. Indeed, CSS is getting more and more popular and the demand is strong to make it much more powerful without changing its model and syntax.

I'll take a quick look at CSS's first 10 years and try to extrapolate to the future, to see how common requests such as complex layouts and more of the world's typographic traditions can be integrated into it.

A difficult task is defining the priorities, for which the CSS working group needs input from implementers, typography experts and users.

Back in 1994, when work on CSS started, I and other people who proposed or worked on style sheets had a number of reasons for that:

• Keep HTML accessible and device-independent by separating out the style information.
• Make documents easier to maintain (by sharing styles among elements and among documents).
• Offer extra style possibilities that HTML didn't provide.
• Make style independent (to some extent) from HTML, in preparation for possible other structured document languages.

We were aware of the bias of CSS to western typography and although we planned to enhance it in several ways (in level 2), we also thought CSS wasn't going to be the last or only style language.

One of the enhancements Dave Raggett, Håkon Lie and myself worked on was the predecessor of the current Advanced Layout module: it allowed several frames to be positioned on the page in various ways and the elements of the document to flow into one or more of them. But at that time the idea was much too advanced for the browsers.

The first W3C Recommendation for CSS, describing level 1, was published in December 1996. And thus from December 2006 until December 2007 we celebrate the 10th anniversary of CSS.

Level 2 in the end contained much less than we expected when we started working on it. It was supposed to contain basically the “rest of (western) typography” with hyphenation, columns, cross-references, proper drop-caps, non-rectangular wrap-arounds, multiple flows, ligatures, shadows, “copy-fitting,” etc. And so we decided, reluctantly, to start a level 3.

But even this level 2 was already too ambitious. The code architecture of the browsers was much worse than I and others had imagined. Now, ten years later, some things are only starting to be implemented. And what was implemented was often implemented badly.

At first we didn't worry about the bugs. All software has bugs and given the rate at which new versions of browsers (and new browsers) were appearing, the bugs would soon be fixed… but they weren't.

The Internet changed a lot in the 90s. The number of users increased tremendously and the new users weren't technical. They didn't compile their own browser, they got one on a CD from AOL or preinstalled with Windows and they never considered upgrading it.

In the role of authors, those new users also didn't write to the specification, but they copied examples and followed books of dubious quality and were happy when it looked right in Netscape and, later, Internet Explorer. They didn't know or didn't care that it looked that way because of a bug in the browsers.

And thus browser makers became reluctant to fix bugs, because whenever they did, people started complaining. The page worked in the old browser, it doesn't work in the new one, so the new browser must be wrong, mustn't it?

A few years after publishing the Recommendation for level 2, the CSS working group decided that it was time for an update, because there were many ambiguities and missing details in the specification that hadn't solved themselves in practice and because there were parts in the specification that hadn't been implemented at all and thus needed to be taken out and moved to level 3.

But what was expected to be a quick rewrite, based on existing implementations, has turned out to be many years of work. Every new draft the working group published made people discover yet more bugs in browsers and yet more undefined details in the specification.

But we have good hope that all the discussions, negotiations and tests have finally led to a specification that is precise and that matches what the various implementations already do or plan to do soon. The current specification has the status of Candidate Recommendation. As soon as the test suite is complete we will be able to say if it can become Recommendation again.

Now that the browsers are getting closer to full support for CSS level 2 (and several already even exceed it) and there are fewer and fewer bugs, more and more people see that CSS is not only a good idea but also a practical choice.

Over the years, the use of CSS has been steadily rising. A little robot that I run every once in a while to sample pages form the Web now reports that nearly three quarters (73%) of all HTML pages use CSS. (Of course, it's impossible to count precisely, because there are infinitely many pages on the Web; and I haven't done an analysis of how random my samples are either, but the same method has shown a steady increase over the years.)

There are four categories of modules for level 3. The first is made up of the specifications that are mostly ready (apart from testing), the other three are the high priority modules (which the working group is actively working on), the medium priority modules (which we work on whenever we have time) and the low priority modules (which we are not currently working on).

The question is always which modules should have the highest priority…

A sample of designer's demands.

There are two slightly different different ways to define the grid, depending on your point of view. In the second example, you can either say there are three columns and the text has some padding; or you can say there are five columns and two of them are empty.

CSS will probably allow both views.

display:
  "a b b c"
  "d e e f"
  "d e e f"

There already was a Mobile Profile, a slightly smaller one. In fact, there were two, one by W3C and one by WAP (now OMA). The two were almost the same, but the fact there were two was confusing.

The new profile is the same for OMA and W3C. (Or more precisely, the new CSS Mobile Profile plus the WICD Mobile profile of XHTML together are equivalent to the OMA XHTML and CSS profiles, because some features that W3C put in WICD Mobile, OMA put in the CSS profile.)

One reason we're late is that the marquee properties aren't quite ready yet. They are based on a previous OMA specification, but that specification wasn't very precise and the behavior needed to be tight in with overflow behavior. Plus, marquee has to remain optional for desktop implementations.