CSS3

This post was written by fantasai on 23-5-2007 on her weblog, she e-mailed us and asked us to put it up here for the greater public to enjoy and be able to comment.

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

In my last post, I explained a little about what we’re doing and how we operate. In this post, I’ll cover the problems I think we have and how I think we should address them.

What needs to change

(Besides companies allocating more man hours to working on css specs. ;)

Problem 1: Lack of web designer perspective

In my opinion, the CSS Working Group has been too dominated by browser implementors and gives too little weight to what web designers really want. For most of my time on the working group, the only representation we had from the web design community was from AOL: from Kimberly Blessing and Kevin Lawver. When Andy Clarke joined the CSS Working Group as an Invited Expert last year, I was really excited: finally some more web designer perspective. But Andy and Kevin are both too busy to be regular participants,and when they are around, they’re not technical enough to really follow the discussions and understand the impact some silly sentence in the spec has on what web designers are trying to do. Therefore our decisions tend to get made from the implementors’ perspective, even when it goes against common sense. Bert and I try to represent common sense, since neither of us represents anything else, but if there’s an impasse between us and the implementors, we’ll get voted down. Very often the working group would seriously consider the position of the web design community if they knew it, but Bert and I cannot represent to them how important an issue is for web designers, and the web designers aren’t there to speak for themselves.

Recently the increased participation of Adobe (Steve Zilles), HP (Melinda Grant), and even Microsoft has helped a lot to balance the excessive bugwards-compatibility bias we had for several years, but we’re still not aligning our work with the needs of the web design community as well as we should. It’s not an easy problem to fix. We need more dialogue between the CSS Working Group and the web design community, but simply putting some web designers on the working group doesn’t make that happen.

Problem 2: Poor communication with the public

Ian Hickson and Anne van Kesteren keep saying that the CSSWG should be restructured like the new HTMLWG, where anyone who wants to can join, and are disgusted that we aren’t seriously considering it. I’m far from convinced that this is a good idea. Making the HTML Working Group actually work is going to be an exercise in herding lots of very opinionated cats. I’m optimistic that as the undisputed master of the HTML5 spec (and an ardent cat-lover), Ian Hickson can pull that off, but we don’t have anyone with comparable ability, commitment, and sense of direction for CSS, and it would also set us up with a single, hard-to-replace point of failure. Ian has made himself indispensable before; it doesn’t work so well when he gets busy doing something else.

Another model that’s often brought up is the WHATWG. But the WHATWG isn’t actually structured more openly than the CSSWG. Its structure is more closed: it’s the communication lines that are more open. Consider:

• The WHATWG has open participation for discussion, and a dictator-editor who writes the spec.
• The CSSWG has open participation for discussion, and a dictator-committee who writes the specs.

It’s not possible to “join” a dictator-editor, but it is possible for somebody to join a dictator-committee. Therefore technically, structurally, the CSSWG is more open. But practically, that’s not what makes the difference in how open the spec-writing process is. The WHATWG’s process is more open because the WHATWG’s dictator-editor has set up multiple communication channels for feedback and responds quickly to that feedback, both with messages to the mailing list and with instantly-public updated drafts. The CSSWG publishes only snapshot drafts, posts little to the www-style list, doesn’t respond readily to feedback, and often doesn’t even acknowledge that feedback until the next working draft. I’ve tracked the CSSWG from the outside before, its a very frustrating situation. I’m glad the W3C is getting pressure to open up and that some of that pressure is being directed at us.

But I don’t think adopting the HTMLWG model is the best way forward. Critical people like Boris Zbarsky (Mozilla) and Markus Mielke (Microsoft) have already commented that they can’t keep up with the influx of mail there, and feedback from people like them isn’t something we can afford to lose. Above all else, the spec has to be something the implementors scan and want to implement.

The CSSWG doesn’t need a radical restructuring to be more open. We have a structure that, IMHO, works reasonably well, and we have a working group culture that is internally pretty open, amicable, and flexible. What’s missing is collaboration with talented and knowledgeable people outside the working group and an open, two-way, quality conversation with the web design community.

I think the best way for the CSS Working Group to open up is simply to communicate better with the public. I would like to see us

• Revamp our website to be more informative and more relevant.
• Publish a CSS Working Group weblog where we can post ideas, explain our work, and invite feedback from the web design community.
• Set up a public wiki where we can share information, keep track of our open issues and our resolutions, collect ideas submitted to the working group for consideration, and collaborate with people outside the working group to improve our test suites.
• Keep editors’ drafts in a public location so people can see our latest version and how we’re attempting to address their feedback.
• Interact more with sites like css3.info.
• Shift all our internal technical discussion to a public mailing list where others can read our comments, decisions, and rationale and themselves contribute to the spec-writing process. Currently www-style is primarily where we take in feedback and have open discussions, and the internal list is primarily where we process feedback into spec text. If we set up some guidelines to enforce that, the traffic on the new list should remain at a tolerable level.
• Open up the entire test suite development process and make it an independent open source project with contributors and leadership and a peer-review system of its own. The CSSWG itself doesn’t have the time, and doesn’t really need, to be running that show.

We discussed some of these issues at our last face-to-face meeting, and so far have already agreed

• To start a weblog! We’ve even got a couple posts on deck (including a less opinionated remix of my last one). Andy Clarke and Jason Teague have volunteered to cook up a hip, cool, and totally accessible new design in the near future, so stay tuned.
• To set up a wiki to track our work. (I set up an unofficial dokuwiki as a demo before the meeting, which I’m still using for test suite work; the official version may have to be a MoinMoin installation, yuck.)
• To maintain our issues lists in a public space, probably the wiki.
• To make it possible for CSS module editors to put their editor’s drafts in public CVS space. (Not all specs will move there, because some of our editors are uncomfortable editing in public, but you can expect anything I edit and anything David Baron edits to wind up there and hopefully most others as well. As David Baron says, he’s uncomfortable not editing in public.)
• To move most of our discussion to a public mailing list once we’ve sorted out the necessary IPR issues. Basically, anyone contributing significantly to the spec would need to agree to the W3C Patent Policy. This will probably take the form of something like a W3C Interest Group: editorship and decision-making power will rest with the CSS Working Group (but as I mentioned before we can always pull specific members of the public in as Invited Experts if we want to let them edit).
• To accept new test suite tests, assuming they at least conform to the guidelines, as correct until proven incorrect.

So we’re slowly making progress on this front, and the main blockers right now are technical, legal, and temporal, not organizational.Hopefully by the end of the year we’ll have set everything up and be working together with the web designers, implementors, and random techies towards a more inclusive CSS future.

As for the CSS2.1 Test Suite, I’ve acquired write access so I can edit it. So far I’ve fixed a few bugs, imported a handful of tests Microsoft submitted, and set up some indexing scripts to make a proper table of contents. I’ll probably be spending much more time there once Mozilla 1.9Beta is out. I plan to set up framework for turning it into an open source project rather than just open-sourced code, and hopefully we’ll be able to get the Mozilla, Microsoft, Opera, Webkit, and Hewlett-Packard QA teams, along with random volunteers, to all contribute tests.

This post was written by fantasai on 23-5-2007 on her weblog, she e-mailed us and asked us to put it up here for the greater public to enjoy and be able to comment.

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.

What is the CSS Working Group doing these days? Why not a CSS2.2?

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:

CSS2.1

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.

“CSS2.2”

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.

CSS3

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

Why is the CSS Working Group so slow? Wouldn’t being more like the WHATWG speed it up?

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

I have time and technical ability. How can I help?

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.

Why can’t you Just Ship CSS2.1 and fix the problems later?

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.

CSS Working Group Myths

Next, I want to set the record straight on a few things:

Myth 1: The CSS Working Group doesn’t invite feedback from the web community.

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.

Myth 2: The CSS Working Group members want to be closed and insular.

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.

Myth 3: Microsoft is holding back CSS standards development and/or doesn’t care.

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.

Continue: problems I see and how I think we should address them.

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!

After the issue of the overhauled CSS3 Text module recently, I wonder if the Fonts module is due for similar treatment? The current working draft states:

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-adjust lets 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-adjust let’s you overcome that problem. The module provides some examples of font height aspects.

font-stretch is 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-effect allows you to apply ‘special effects’ to your font; choose from embossed, engraved, or outlined text.

font-smooth switches 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-style and 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.

For example, imagine the opportunities with the XFN microformat; by combining this with the partial attribute selector, you can add a little flourish to your pages.