Lately there’s been a lot of talk about the CSS Working Group and about how we’re closed, out-of-date, slow, and/or dysfunctional. I’m acknowledging Andy Budd’s post here and other comments. It’s not very clear what we’re working on or why it’s taking so long, so I decided to write couple posts, from my perspective as a CSS Working Group Invited Expert, on where we are, why we’re here, and where I think we should be going.
Disclaimer: This is my personal viewpoint and does not necessarily represent the perspective of anyone else.
First I’m going to answer a few questions that seem to be floating around.
For those who think CSS2 was finished quickly and now CSS3 is taking forever… CSS2 wasn’t finished. It was published as a W3C Recommendation because back then, a Recommendation was the same as a Candidate Recommendation is now and got even less scrutiny from experts like David Baron and implementors like Boris Zbarsky. So CSS2 will actually be finished when CSS2.1 is finished. It’s not done yet.
The CSS Working Group is working on three things these days:
- Unless you’re tracking every issue, it’s hard to understand how much work has gone into CSS2.1. It’s not just taking a “snapshot” of CSS support as of 2002: most of the work is going into fixing hundreds of loopholes, mistakes, and conflicts between the spec and implementations or the spec and itself. There’s no immediate practical benefit to web authors, but the implementors need a super-precise spec in order to all aim at the same behavior. Minor cross-browser incompatibilities drive web designers nuts. Having a common goal for each of these will help implementors make those go away.
- We’re not working on a CSS2.2 as such, but that’s because CSS3 is modular. We’re working instead on cutting down and/or refining features in earlier CSS3 drafts in order to get some CSS3 modules into a stable, implementable state. Selectors has already made it, CSS Namespaces is almost there, and believe it or not, CSS Backgrounds and Borders is pretty close.
- Some of the CSS3 modules out there are “concept albums”: specs that are sketching out the future of CSS. Among these explorative specs are CSS Advanced Layout, the outdated CSS Generated Content, and the more recent CSS GCPM (a miscellaneous collection of print-oriented features).
Most of our focus as a group has been on CSS2.1. Progress on otherdrafts depends entirely on whether we have an interested editor who’s putting in the time.
Drafts that have been pulled back from CR were pulled back due to problems in the CR. If a specification needs substantive changes,even minor ones, it has to be returned to working draft status.Selectors was pulled back for relatively minor changes; CSS2.1was pulled back for lots of tiny to medium-size changes; and CSS3 Text was pulled back for a complete rewrite (see e.g. my comments from 2003).
It’s mainly about time. The active CSS Working Group members all have very busy full-time jobs, many of them at the manager level. These members would love to spend more time on moving CSS forward, but due to their many other responsibilities, just can’t. It’s been argued by some that being a committee rather than a dictatorship is inefficient,but aside from CSS2.1 and other CR-level drafts where we need to make sure all the implementors are on board with any changes, the CSS WG only exercises loose oversight on a spec editor’s work: ultimately the bottleneck is the total amount of time×skill spent banging at the keyboard.
(Notice that the WHATWG has an extraordinarily talented and knowledgeable spec-writer working more or less full time on the HTML5 spec, and the draft is still in the unfettered-development working draft stage.)
- Comment on our work
- Our specs are open to public comment. Look them over and give us feedback. Tell us about our grammar mistakes and logical loopholes, or pros and cons about a particular feature’s design and how to improve it. Send us examples we can add to better explain the prose, or suggestions for features that would really make your day (and make sure you explain the inspiring scenario that’s giving you a headache right now). Most of us aren’t web designers ourselves, so we need well thought-out comments from that perspective.
- Help with the test suite
- Each stable CSS spec has an associated test suite. The test suite serves several purposes: it helps implementors see their bugs and fix them; it helps spec writers see their bugs and fix them; and it lets the spec qualify for Recommendation once two implementations pass it. The CSS2.1 test suite needs many more tests to be complete. It also needs people to review each test and make sure it’s still correct with respect to the updated specification. So if you’re not up to writing new tests, point your favorite browser at the CSS2.1 Conformance Test Suite and see where it fails. If a test fails in more than one of Opera, Mozilla, or Safari and you’re not sure the spec’s prose is backing up the test’s failure, send an email to [email protected] asking for it to be reviewed and I’ll take a look.
- Become an editor
- While anyone can comment or contribute to the test suite, becoming an editor is not as simple. Writing good specs is a skill, just like programming is a skill. Even just reading specs and interpreting them correctly is a skill. If you have that down and feel you know CSS and its design principles inside-out, you can consider becoming an editor. If there’s a spec that isn’t moving and you really want to help push it forward, start by commenting. Review it as if you already are the junior editor, and the current editor is your senior co-editor. Post emails to www-style explaining what needs to be fixed and why with specific replacement text that will solve the problem. If you’re good, and we feel we can give you responsibility for the spec without needing to look over your shoulder, we’ll make you an invited expert and assign you to the spec. David Baron, Ian Hickson, and I all started out by commenting in www-style and from there became invited experts.
You can Just Ship software with bugs in it to put out a new stable release because it’s versioned. The next version replaces the old. You can always fix the leftover bugs in the next version. CSS doesn’t have versions. Any problems there are in the way CSS2.1 defines things can’t be fixed in CSS3 except maybe by adding really confusing sets of switches. CSS3 cannot change anything in CSS2.1, it can only build on top of it.
Next, I want to set the record straight on a few things:
The W3C has had an open, archived mailing list dedicated to getting feedback on style sheets from the public since before there was a CSS Working Group. It’s called [email protected] and anyone can join, post, and participate in discussions as long asthey agree to let the W3C archive their comments. We publish public drafts of our specs precisely so that we can get comments from web designers, implementors and random techies.
If you’re posting a weblog entry about one of our specs, whether you’re famous or not, chances are we won’t see it. Post the URL to www-style, or at least private-message it to someone and ask them to post it for you. Don’t be shy: we do want to hear your opinion, good or bad.
The W3C standards development process has historically been somewhat closed: public mailing lists were available for discussion, but decisions were made behind the scenes by committees of paying W3C members. From what Bert (our chair) has been saying over the years, there seem to be several reasons for this:
- The W3C needs cashflow to operate, and it gets this by signing up members. The companies obviously want some benefit for forking over so much money, so they get
- early access to drafts
- access to the W3C’s internal archives
- decision-making power in the working group
- Since the decision records are member-confidential, there’s no public record of who blocked or pushed for which feature, only a final resulting spec.
- Since discussion records are member-confidential, reps can share not-quite-public information from their companies as necessary.
- Participation in the W3C requires agreement to the W3C Patent Policy, so that W3C technologies can be implemented royalty-free. The agreement encompasses not just the individual representatives or departments involved, but all the patents owned by the member company. (This is why the W3C refuses to sign up invited experts who work for companies that operate in the same domain. They instead demand that the company as a whole pay the membership fee and join, because an invited expert is only responsible for the patents he or she personally owns.)
As Daniel Glazman would have one believe with his stories of confrontation at the table and smoky-backroom negotiations in the hallways back during the Netscape-Microsoft browser wars, reasons #2 and #3 were probably much more important in the past. Nowadays, the CSS Working Group makes almost all its decisions by consensus. Very few decisions have come to a vote. Very little confidential information is shared. We’d be happy to open up more of our records to the public, and we resolved at the last face-to-face meeting that we want to shift all our technical discussion to a public mailing list if we can just sort out the inevitable IPR issues.
I do believe the CSS Working Group can and should be more open, but the reason we’re not more open is a lack of time and pressure to overcome the bureaucratic overhead and inertia, not a lack of desire to interact with the rest of the world.
I have no idea what Microsoft Corporation’s agenda is, but ever since they rejoined the CSS Working Group, the Internet Explorer team has been actively participating in the working group. Markus Mielke has been consistently pushing us to spell things out explicitly one way or the other rather than leave anything undefined, and most recently Paul Nelson, whose expertise is in internationalization and fonts, has volunteered to pick up some of the specs whose editors left the working group years ago. That’s not the behavior of a group that wants to hold back standardization. Markus’s team wanted to fix more bugs inIE7, but the release schedule didn’t give them the chance to make many of the changes they wanted. The company as a whole may be trying to undermine the Web’s openness, but the reps they send to the CSS Working Group genuinely believe in cooperating through the W3C and moving forward with web standards.
I’ve put the new layout online! Of course I know work needs to be done on it, but I know myself: I’ll only do that when I put the new thing live :). The sidebar is widgetized, and I’ve tried to use as much css3 features as I could ;). I’ll be adding fallbacks for all the different css3 stuff in the coming days, for now, it looks best in a WebKit nightly build, and it looks pretty good in Firefox too… Let me know what you think!
Of course I need to thank Laurens, from TND media, for creating the design in Photoshop!
I’ve got a nice idea for a new extension to css3.info: a gallery of sites using CSS3 as an important aspect of their design. For that gallery I’d like you, our readers to submit your designs! Drop them in the comments, and I’ll create a cool gallery, which might feature your site!
In other news: this site will be getting a new layout in a few days, a first step towards making this site even bigger and better than it already is. Because we want to continually improve this site, Peter and myself would like to have some more people working with us on this site. If you think you can write nice posts for this site, or help us in any other way, please contact us through the contact form.
April 5th this site will be going naked, yours too? The CSS Naked day was instated to promote Web Standards, the proper use of HTML etc. And it’s a fun play on words too: we will be showing off our <body>! Join in on all the fun!
The working group believes this draft is stable and it therefore issues a last call for comments, before requesting the status of Candidate Recommendation for the draft. The deadline for comments is 30 August 2002.
Four and a half years ago! That’s a long feedback process!
The module introduces a few new features into the coder’s lexicon, and although none of them are truly essential, they would be very useful; there is so much text on the web, but typography is the least-developed aspect of CSS.
font-size-adjustlets you preserve the height of type even if the user doesn’t have your first-choice font installed. Certain fonts have higher height aspect than others, so type that you’ve carefully styled to appear at a certain height could suddenly appear smaller if font substitution was used.
font-size-adjustlet’s you overcome that problem. The module provides some examples of font height aspects.
font-stretchis useful when displaying font families with condensed or extended faces, such as Arial. You can select absolute (condensed, extended, etc) or relative (narrower, wider) values.
font-effectallows you to apply ‘special effects’ to your font; choose from embossed, engraved, or outlined text.
font-smoothswitches anti-aliasing on or off. Fonts look so ugly without anti-aliasing, I can’t imagine a situation where you’d ever turn it off!
Finally, three declarations with limited use outside of East Asia:
font-emphasize-position, along with the shorthand
font-emphasize. These are used only to set emphasis on East Asian characters.
Will this module make it to recommendation in this form? Or will it make a comeback in altered form? I suspect the latter. But I think the most radical change to web typography will come not from the implementation of this module, but from the implementation of @font-face, which will facilitate the use of non-core fonts.
By the way, anyone interested in web typography should, if they haven’t already, read Richard Rutter and Mark Boulton’s Web Typography Sucks presentation. It’s a 4MB PDF download, but well worth ten minutes of your time.
As you might have seen, we have moved the blog from /blog/ to the main domain, since the homepage wasn’t exactly useful anyway. In the process we have moved some pages that were static into WordPress, and we will be doing that for most other pages as well in the coming weeks. If you see glitches, feel free to mail us, we’ll try and fix it.
As one of our readers has pointed out to us, the latest (3.5.6) release of the KHTML rendering engine passes all of the tests in our CSS selector testsuite – making the Konqueror 3.5.6 browser the most CSS3-compatible of all.
Also in the latest release is the implementation of text-overflow: ellipsis. It really is a shame that only a tiny proportion of web users have access to this excellent browser.
David Storey, Chief Web Opener at Opera, has announced on his blog that the latest internal builds of the Opera browser have advanced CSS3 selectors support.
Some of the new selectors are already enabled in the builds, while others have been implemented but not yet enabled due to technical reasons. All are hoped to be available in a future release version.
IE7 is gaining market share and we can start to use more CSS3 selectors in our day to day code. Because of this, it’s worth a quick reminder that the more semantic we make our (X)HTML, the easier to implement the selectors will be.
He raises the point that not every internet user wants their browser upgraded every year, saying:
During the open mic session [at the Mix conference], someone said "please don't ship a browser every year – I can't handle that"… [There] are people who say, "I'm using an extranet in order to get my billing done and I'm scared. I really don't want browser changes because this is how I get paid".