Conversation with CSS 3 team


CSS 3 is arguably the most eagerly anticipated specification in the works at W3C. CSS 3 promises to make it easier to create page layout and to support formatting that is currently only achievable through hacks. In this article, interviews Bert Bos, chair of the CSS Working Group at W3C, about the next release of the CSS specification and how past design decisions are influencing the future of CSS. This interview offers a rare opportunity to learn more about the inner workings and thought processes of the CSS Working Group at W3C.

Bert Bos bio

Bert Bos joined W3C in 1995, to create and lead the organization's Internationalization Activity, whose mission is to ensure that W3C's formats and protocols are usable worldwide in all languages and in all writing systems. Bert is however most readily recognized as one of the original authors of CSS, which he began working on, with Håkon Wium Lie, a year before joining W3C. Bert and Håkon went on to collaborate on the widely respected book Cascading Style Sheets: designing for the Web. Since joining W3C, Bert has contributed to work developing HTML and XML, and he now leads W3C's CSS and Mathematics activities. An essay on W3C's design principles written by Bert is a must-read for anyone interested in learning how standards for the Web are written. Bert has a PhD in mathematics and lives in beautiful Provence, in the south of France.

It's been about 8 years since work started on CSS 3. The first question most people want to know why it is taking so long to finish the CSS 3 spec. What are the challenges the CSS Working Group is up against that are affecting completion of the CSS 3 spec? When do you anticipate CSS 3 will be released (become a Recommendation)?
Bert Bos

There are several factors:

  1. The work on revising level 2 proved to be much tougher than we expected. It had priority over developing level 3, because it makes little sense to add new features if the more basic features of level 2 are not reliable yet. So work on level 3 has been light and is only now getting more intense.

    The Web has changed since 1998, when we published the Recommendation for CSS level 2. In the current context, we wouldn't call that spec a Recommendation, it would at most be a Candidate Recommendation, because it was published without implementations. At the time, the Web was made up of far fewer people and much more technical ones. Bugs in the spec or in the software weren't seen as important at the time, because in the course of using the spec, people would discover them, update the software and the spec and over a couple of months things would become stable…

    But then a very large group of very different users discovered the Web and they were not the kind that recompiled their browser every two weeks. They also didn't understand why some pages were broken and simply blamed their browser. Thus browser makers became more and more reluctant to fix errors and instead were obliged to copy each others' bugs.

    Before that, W3C hadn't needed to do anything to make software converge. The universal support for PNG, GIF and JPG (and the lack of support for XBM, XPM, TIFF and many others) had happened all by itself. But from the end of the nineties, we discovered that we needed to define error cases and test suites before the first implementations, because afterwards it was too late. Thus was born the Candidate Recommendation process in W3C, but it came too late for CSS2. (Typically, W3C now requires two implementations of a specification before allowing it to become a Recommendation.)

    There were many ambiguities and errors in the CSS level 2 specification, but we couldn't just fix them, we had to carefully negotiate what to do with the error cases.

    For example, a block that is centered but is wider than the containing block, would, per the old CSS level 2 specification, stick out equally on both sides. Somehow most browsers forgot about that case and only used scrollbars that could scroll to the right, but not to the left. People then started using that to hide things to the left of the window. And now the spec has an explicit rule that says that wide blocks aren't centered. It looks ugly, but it was necessary. (People who want to center wide blocks have to use a work-around, via absolute positioning.)

    I believe we have now seen the end of the discussions of level 2. We haven't completed the test suite yet, but it is growing steadily and we have now time again to discuss new features, in other words: level 3.

  2. Another factor in the slow development of level 3 is the speed with which implementations arrive. We can discuss features, but we also need to experiment with them in practice. And browser makers have few free resources for that. The work on fixing bugs in level 2, plus all the other things they have to do (security fixes, implementing other formats, such as JavaScript, MathML, HTML5, XHTML, and others) keeps them from implementing new CSS features just for experimenting with.

    And when they do implement them, such as rounded corners in Firefox and Safari, multiple backgrounds in Safari, columns in Firefox, media queries in Opera, vertical text in IE, etc., it is often because a need that one vendor has and the others not, so we end up with just one implementation. And thus, even if the specifications are quite stable, we can't go further than making the module a Candidate Recommendation, for lack of a second implementation.

    I'm confident that the various browser will eventually implement the stable modules of level 3, but the browsers have sufficiently different "markets" that they are likely to implement modules in a different order. E.g., some look primarily at what is needed for mobile phones, others focus on Web-based applications (such as widgets). And they have many modules to choose from…

  3. Level 3 is, of course, a lot of work. So it is no wonder if it takes time. All together, the number of new features that people ask us for amount to hundreds of pages of specification. They all need to be written, discussed, compared for contradictions, explained to users, etc.

    People may think that things they ask for are simple, but usually they aren't. Somebody may want a rotation property: rotation: 15deg, simple, isn't it? Well, no. What happens if you rotate a floating image, how does the text wrap around it? What happens if you rotate a block, does it overlap other blocks or does it increase in height? And so on. The end result should be simple to use, but making things simple to use is, paradoxically, a very difficult task…

    That's why we have divided the modules in high, medium and low priority.

    A big question is, of course, how to determine the priorities. Who can say if user A needs feature P more than user B needs feature Q? We try to assess the demand and also look at what is easy to specify, what implementers believe they can implement and what current hardware is capable of.

  4. And, finally, things take time because we need to acquire the expertise. We can't make the working group too big, because that in itself will slow down the work. But with few people, it is inevitable that there are gaps in our knowledge. Few people in the working group speak Japanese, and still we have to define how Japanese text is laid out.

    Luckily, we can find Japanese experts (and W3C has set up a joint task force among the groups for XSL, Internationalization and CSS for them, where they discuss in Japanese with translations to English afterwards), but finding experts for Thai, Mongolian, various Indic languages, Somalian, etc. is difficult. Of course they exist, but how do we find them and how do we communicate with them in English? That takes time.

Meanwhile, some modules are stable and implemented (although we haven't formally tested them yet, for lack of a complete test suite, and so they remain Candidate Recommendation for a while). The Selectors module appears to be 99% implemented, judging from the first test reports we have; the Color module (which allows transparency) is not far from that either; and the Namespaces module seems to be fully implemented as well.

Over the next four or five years most of the modules will become implemented, I think, and the rest we will drop definitively. I can't tell you which ones, though…

We have actually decided that there may be a level 4, but only for some modules and only if "market" pressure obliges us to split modules into a short-term and a long-term part. For example, we may have a Box Module level 4 (with advanced float wrap-around rules) and a Multicolumn level 4 (ditto), but it is unlikely we will have a Namespaces level 4.
What are some of the new features in CSS 3?

As I said above, the things that we consider stable include the Color Module, Selectors and the Namespaces.

The Color module allows semi-transparent colors. You can make text, borders or backgrounds that let the underlying elements shine through. You can also specify colors in HSL notation, which some designers find more intuitive than RGB: You can change the color independently from the lightness, which with RGB requires a tool, such as a color wheel.

The new selectors considerably reduce the need for IDs and classes in the source. You can now select, e.g., every 2nd element, even if you didn't add classes to those elements when the you wrote the source. You can also negate selectors, and select all elements except certain ones. E.g., you can style all elements that don't have the focus.

The Namespaces module is very small, very simple, and probably rarely needed, but just because it is simple, it doesn't cost much to add it to CSS. Indeed, many browsers have supported it for a long time already.

The only thing it defines is how to declare an XML Namespace prefix in CSS. That is needed if you want to use selectors that only match elements in a certain namespace. For example, you can since level 1 already match the SVG "circle" element with

  1. circle { color: green }

or, if you're afraid there may someday be other "circle" elements in your document,

  1. svg circle { color: green }

But namespaces allow you to be absolutely precise, at the cost of some reduced readability:

  1. @namespace svg "";
  2. svg|circle { color: green }

(That is the correct namespace, I actually looked it up.)

B.t.w., the reason the Selectors module doesn't contain the @namespace rule is that Selectors is meant to be independent of CSS syntax. And indeed Selectors are used in other contexts, such as Javascript libraries and XBL2, which have different syntaxes for defining namespace prefixes.
The history of CSS has been plagued by buggy implementations (i.e. Web browsers incorrectly rendering certain CSS properties). Why do you think this problem still exists with modern Web browsers? Also, just as prevalent is the problem of partial implementations (i.e. some CSS properties or selectors are not supported by some Web browsers). What is being done to address this problem?

As I explained above, under question 1, CSS was caught in the unexpected change of the Web's population. We didn't write test suites until too late, when errors couldn't be fixed anymore.

I'd like browsers to fix bugs as soon as possible, but it is true that they (and not me) will get the complaints from users when pages that used to work suddenly look differently in a new browser version. Too many people see the Web a bit like television: who ever heard of incompatible content? If there is an error, it's because the TV set is broken, or maybe the antenna. On the Web, it is much more likely that the content is invalid, but try to explain that to users who just want to buy their holiday or see their bank account…

So browser makers are struggling to find ways to progress. Fixing bugs is necessary, otherwise new features can't be added. But how to avoid the complaints? The smaller browsers can sometimes do small improvements, but mostly they wait for the big ones to take the hit and educate the users.

The problem of partial implementations, I think, is a combination of two factors. One is that the different CSS implementers have slightly different "markets" (as I mentioned above). Some are more focused on mobile phones and portable devices, others on Web applications, or on intranets. Some operate more in Japan and others more in India. That means they have different priorities. The second factor is that typography is such a vast subject and there are many things that we need to add to CSS. So if implementers prioritize features in different ways and there are many features, it will take a long time before all features are implemented everywhere.

Although W3C or the CSS working group can't set the priorities for implementers, the implementers are represented in the working group and they do talk about what they are interested in (as far as they are allowed to say and as far as they can predict, of course). That doesn't lead to a common implementation schedule, but it does lead to some idea of what the implementers believe are stable features. They won't promise to implement them soon, but they do believe they will implement them exactly as specified. The idea is that users will increase their lobbying for those stable features, which may in turn change the priorities for the implementers.

W3C tries to talk to as many parties as possible and give a fair balance to implementers and users, both professional users and others. In the case of the CSS working group that means that the group has recently started a blog, because the current fashion seems to be more to use "trackbacks" than e-mail threads (which the group has used since its inception, and continues to use, of course, on
When writing CSS by hand, it's really easy to make simple mistakes such as omitting a semi-colon or a closing bracket. As a consequence, formatting is not applied to Web pages as the author intended. Unfortunately, most people who build Web sites use Web browsers as their error-checkers, and since CSS does not require Web browser to report errors, in practice this means there is no error-checking going on. For CSS written specifically to level 3, why not require that Web browsers report CSS errors or simply not apply CSS formatting when CSS is not written correctly?

Browsers may report errors, and some users do turn that feature on. But most users don't want to be told about errors in pages that they didn't write.

The revised CSS level 2 has very precise rules about what happens in case of an error. Usually, the error causes some specific part of the style to be skipped. We can't force authors to use tools that report errors, but we can protect users of those erroneous pages from seeing random differences from what the author saw.

I don't see any chance of getting forced error reporting into the specification. What do you think the implementers will say? Which one will be the first to turn that feature on? And what will users do when they are suddenly confronted with error pop-ups on every other page? Most likely they will downgrade to the previous version…

The trend is more towards making sure that all implementations deal with errors in the same way. Whether they are reported or not, we want, in the extreme case, a random stream of bytes to give the the exact same result in all implementations. We're not quite that strict in practice, but there are few undefined cases anymore.

That doesn't mean we can't extend CSS. We have very specific areas, already defined in the days of CSS level 1, where browsers have to skip unrecognized rules. Those areas allow us to add new features and so far we haven't found anything that we wanted to add that we couldn't. (Except in some rare cases where buggy browsers didn't skip as they were supposed to. E.g., some browsers didn't skip a rule that started with //, making it impossible for us to use double slash for anything in the future Emoticon: sad.)
I suspect many people haven't noticed that CSS has no version identifier. One of the consequences of having no version identifier is that CSS 3 can only build on top of CSS 2.1. In other words, new features can be added but bugs and poor design issues cannot be fixed. What drove the original decision not to include a version identifier and how has this affected the evolution of the CSS spec?

The working group has recognized since a long time that version numbers for document formats (as opposed to software) are a fallacy. HTML has version numbers (inside the DOCTYPE), but implementations either ignore them or use them for something else ("quirksmode").

Formats may evolve and be extended, as HTML and CSS are, but implementations won't provide different parsers for the different versions. They only implement the current version. The new version better be backwards compatible, or disaster will ensue. You might think that putting in a version number will cause old implementations to refuse documents that are too new, but it doesn't. None of the browsers written in the days of HTML2 will refuse to handle an HTML4 DOCTYPE. And none of the current HTML4 browsers will refuse an HTML5 document once HTML5 becomes a standard. No browser wants to admit it can't understand something and users don't want to use new features if that causes the whole file to fail.

The basic problem is that old and new software and old and new content have to coexist. It isn't possible to pick a day and switch all content and all software in the world over to the new version. And on the Web, some software, and especially some content, have very long life spans.

If a format can't be extended anymore, the only solution is to create a new one, with its own MIME type. That's the only way to be able to provide two versions, one in the old format and one in the new. If the two versions have the same MIME type, there is no way to serve different files to different implementations.

What people are really interested in when they ask for version numbers is a way to target specific implementations. They want to write one style sheet for Firefox and another for Microsoft. Version numbers won't help to distinguish those, because both implement the same version. They just have different bugs.

And what would it mean to support level 3? For the moment, level 3 has some stable parts and some parts that won't be implemented for another few years. What does it mean to say that a style sheet is a level 3 style sheet? Does it mean the style sheets relies on level 3 selectors (which many browsers already provide) or that it relies on Ethiopian numbering in lists (not expected for the next few years)?

Some people have suggested putting in a feature list instead of a version number: "This style sheet uses the properties X, Y and Z, please ignore me if you don't support them correctly." The problem is that browsers will say they support X, but by definition they don't know if their implementation is buggy. For example, MSIE6 would in this case declare that it supports position: fixed and indeed it parses the value correctly, but it's so buggy, you can't use it at all.

Putting special selectors for browser versions at the top of a style sheet has also been suggested. The problem, as is shown by Javascript, is that the small browsers will lie and say they are Mozilla, because most authors forget to write style sheets for small browsers and thus these browsers would not get any content at all.

So what is the incentive for users to put in a version number? If putting in a low number means that certain features are not supported, they will simply put in the highest number. So their style sheet contains nothing that implementations must ignore and as we have to keep CSS backwards compatible, their style sheet will continue to work identically if new versions arrive. So with or without the version number the style sheet means the same thing.
Some are advocating a one-time or even regular point releases of the CSS spec as a means of getting the most needed features into production faster. A point release, for example CSS 2.2, could include the 10 most eagerly anticipated properties currently slated for CSS 3. Is this feasible?

As I said under question 3, the working group can't determine what gets implemented when. All it can do is declare what is stable and then wait for implementations. So what part of level 3 will be usable at any point in time doesn't depend on anything we write. It's better to look at sites on the Web that document bugs in browsers and judge from that which parts are usable enough for your purposes. (Some people may use features earlier than others.)

On the other hand, we do recognize that what is "stable" is in itself an interesting question and one that is difficult to judge from the official W3C document statuses: Working Draft, Candidate Recommendation and Recommendation. A Recommendation is pretty safe, but some of the others may be safe to use as well, even though there aren't sufficient implementations yet to make the spec a Recommendation.

The working group thus decided recently to make a regularly updated list of modules that, in the eyes of the working group, are stable. They may be Working Draft or Candidate Recommendation for technical reasons, but, as far as the working group can see, they won't change anymore. If you use features from that list, they may not work yet, but at least you won't have to change your style sheets once they do start to work.

And, we hope, people will let the implementers know which of the stable features they need or like best, thus maybe changing the implementers' priorities…
What are some of the dos and don'ts Web designers should follow when authoring CSS? What are the best practices Web designers should follow in order to write better CSS?

There are the usual guidelines about not relying on particular screen or font sizes, but allowing the reader to choose those. It's important for accessibility and usability, but also because screens of new sizes appear all the time.

The em unit is still the mainstay of CSS style sheets. Although the px isn't as evil as some people make it out to be. It is better to use px than pt or cm, e.g., because at least the px will automatically scale based on the type of device. However, it won't scale the same way as em, so em is better: on a 100dpi screen, a px is exactly as readable as on a 200dpi screen, but on a 150dpi screen, it may either be considerably smaller or considerably bigger…

Still on the topic of px: I'm very happy with the increasing support for SVG in browsers. You don't have to guess the right size for images anymore (or suffer raster effects if you scale them). SVG images scale to any size in 'em' without looking unsharp.

Another obvious guideline is not to use syntactically invalid rules, even if they happen to "work" in some buggy browsers. E.g., some old browser may read width: 7 as meaning 7px. One day that browser will be fixed and your rule will stop working. The value 7 may in the future mean "7 times the intrinsic width', probably not quite what you had in mind…

On the other hand, using valid rules that happen to not work in some browser isn't dangerous. When those browsers get fixed, the rule will start working and the style sheet will still do what you wanted it to do.

But the most important rule is still to never rely on CSS to fix a bad document. CSS can make documents beautiful, but the documents should be readable by themselves in the first place.

CSS has already lasted longer than I expected in 1994, but I still believe that HTML documents will outlive their CSS style sheets and be used in contexts where there is no CSS.

We, in the CSS working group, will do our best to make this goal of stand-alone HTML easier to achieve, e.g., by means of the Advanced Layout module, which makes it a easier to lay out documents in a two-dimensional space while still allowing them to make sense in a one-dimensional space.