Slightly ajar

Disclaimer: The following post is my personal opinion, and not necessarily those of my employers. My colleague, Chris Mills provided feedback and suggestions for this post.

Since Opera’s antitrust complaint to the EC, some people have used the complaint as a catalyst to promote their agenda against the W3C and the CSS Working Group, with arguments flying on either side. There is no doubt that there are issues there, and action is needed. Transparency is one such issue, with many CSS3 modules not having been publicly updated since 2002. This gives the impression that it is moving at an unacceptably slow pace. There are also accusations that in fighting is delaying progress to suit various parties' own agendas. I’m not a member of the W3C CSS Working Group, so I can’t comment on how true this is, as I don’t know. I do know however that something has to be done, and the W3C has starting to make progress on remedying this issue. In this post I state where I feel the working group is right now, and propose some changes that I feel will help move things forward.

The current state of proceedings

Lets start with what they have done. They recently started a blog, in which they report on progress and issues. They’ve also created an aggregated feed of blogs and sites to report on CSS3 so that they can hear the voice of people that are discussing CSS3 outside the W3C, ie real world developers. They’ve also started working closely with css3.info. We have a CSS Soap box to let everyone get their issues off their chest, and they have written posts requesting feedback from designers saying what they want from certain properties. Is that far enough? Maybe not, but it is a beginning and I commend the work that Fantasai has done on this outreach.

Transparency of the Working Group

If this is where we are, where do we want to go? Firstly, transparency and accountability have to be greatly improved, so that if anyone is trying to hold up the process or are playing politics this is exposed, whether it is Opera, Microsoft, Mozilla or anyone else. I propose that minutes to meetings and any important documents or drafts are published on the working group blog.

Who should be represented on the Working Group?

Next, there are calls for browser vendors to be removed from the group. This is unworkable (disclaimer: I work for a browser vendor), for many reasons already exposed. I do strongly believe however that a better balance between designers, browser vendors and other parties has to be reached. Gibson or Fender don’t get guitar players to design their guitars - that would be ridiculous, as guitar players can play guitar, but the vast majority of them have very little knowledge of the processes involved in actually building a guitar. They design them themselves, with input from guitar players on what they want. Writing specifications is very difficult, especially when making sure they are implementable in not only a cross platform, device and browser independent way, but also cross culture and language. Test cases are difficult to write. Browser vendors have many of the best people in the business for writing these specs, as they are the kind of people we hire. Ian Hickson is widely regarded as one of the best specification writers of our generation, and he used to work for a browser vendor.

Keeping browser vendors out of the Working Group would also be difficult to police. For example Fantasai works for HP (I believe), but has close ties to Mozilla. Would she be counted as a representative of a browser vendor? Also, would designers be willing to give up what they are passionate about (designing web pages and other media) in order to work full time writing technical specifications? Why also should browser vendors be reduced to an advisory role, for technologies they have to do the hard work in implementing? If this were to happen, we would probably end up with a break away group similar to the WHAT-WG, of browser vendors that don't want to be told what to do by designers.

A power struggle isn’t what is needed - instead, we need a balance between vendors and designers. The specs should be left to the people that are good at writing specs, and enjoy it, the designers should be there to comment on if the proposals are useful in the real world, and the browser vendors should be there to comment on their side of things - whether the proposals are realistic to implement in their rendering engines.

The designers included could be part of an advisory panel of respected designers (CSS11 for example), adding more invited experts that are willing to spend their time on this and/or having a place where designers can post and discuss mock ups of what they want to be able to do with CSS3. CSS3.info for example could create a wiki where screenshots of desired effects for CSS3 properties could be added by designers, and the merits debated. New proposals could also be added. The WG could then refer to that site for ideas and to solicit feedback. I personally think that the HTML5 working group has far too many invited experts, so limiting the group to a select number, but allowing anyone to leave feedback would be more ideal. It is important that feedback is gained from multiple sources however - the needs of a Japanese designer is probably very different to the needs of a British designer, for example.

Speed of CSS3 development and relevancy of proposals

Furthermore, the speed of development of CSS3 must improve. Making the process more open to inspection will help this by making it harder to use stalling tactics. Action needs to be taken here - I’ve tried to get designers to send me feedback on what standards features they’d like to see in Opera first, but this is difficult, and I received little response. What we need to do is set clear priorities of CSS3. First we need to get the ’07 snapshot finalised (it is currently in Working Draft) and get browser vendors to implement those modules. This is going fairly well at present in three out of the four major browsers. It could also be going well in IE8, but we’ll have to wait to find this out.

In parallel we need to get a list of what properties designers most want to be able to use. Gather the most talented spec writers in the group to work full time, or as much as their employers allow, to mature those specs. It can be finer grained than a whole module, if other parts of that module have issues and are not related to the core properties that are needed. At each iteration, designers should review the progress to see if is moving in the right direction, and the feedback solicited from the working group if there are questions. Properties that have reached proposed final form should be marked as such, even if the rest of the module isn’t ready. These should then be given to the vendors to implement with the dash vendor prefix. Test cases should be built in parallel. Vendors should submit all that they have, while designers should help with this process if possible. The more test cases, the more likely it will be interoperable and the standard will be finalised sooner. These properties or modules should then be added to the CSS snapshot for the current or next year.

One question will be definitely be asked - which modules should be made a priority? Vendors will have an opinion on this, as it depends on the aim of the browser. Apple and Opera will care more about Media Queries than a vendor without a mobile browser, for example, but largely I think this should be down to the design community. If we had a public wiki to discuss this on, I’d suggest the modules or properties with the most active suggestions would be up there, while ones with no activity would be pushed to the bottom. Through the feedback I have collated, designers preferences seem to be borders & backgrounds, selectors, multi-column layout and web fonts, and there has also been interest in the grid layout (although this seems to be the furthest back in terms of both spec and implementations).

Another issue is who will work on these. That isn’t a question I can answer, but if we can somehow get the existing working group to be able to spend more time on it that will help. I’m willing to help out if desired. It should be easier for big companies such as Yahoo! to supply people to represent designers as they have the resources. The problem is that many of the most highly regarded and vocal designers are freelancers that can’t afford to give their time for free. We need to find a solution for this, be it through sponsorship or other means.

Can browser vendors work together?

The other concern that has been raised is that, in light of Opera’s complaint against Microsoft, the browser vendors wont be able to work together. I don’t believe this to be the case. Håkon has stated he has no problems with Microsoft employees, and I’ve personally heard him say he has great respect for the likes of Chris Wilson. I’ve also heard the same coming from Chris. I know or have worked with the likes of Chris, Markus Mielke and Joshua Allen for a while now, and I very much hope that continues. I’m sure they’ll also agree.

Conclusions and the way forward

What we need most of all is action and not talk. I propose the following:

• Get a priority list of CSS3 modules or properties hammered out for both the W3C and the browser vendors
• Get the modules included in the ’07 CSS snapshot to recommendation stage, and push browser vendors to implement them
• Aim to get these priority modules ready for the next CSS3 snapshot ('08)
• Put a mechanism (such as a Wiki mentioned above) in place to give feedback on the issues the WG come up with
• Promote the said mechanism to developers in multiple countries, such as those that use none-latin scripts, and right to left text
• Re-engage the Web Standards Project (WaSP) to take an active role in the activities
• Get the W3C to open up the private communications of the WG, so there is transparency for all to see. Post communication on the Working Group blog or another suitable medium
• Get an official statement from each of the browser vendors on the working group that they are willing to work together in a co-operative and unhindered manor
• To ensure a fair balance between designers and browser vendors on the working group, build a short list of respected designers or developers who should represent designers on the working group. We can get a respected designer like Molly or Zeldman to propose people, again making sure there is diversity of opinion.

Find a way to fund these designers, either through W3C funds or corporate sponsorship

Ensure the chosen designers can commit the required time to the project

Ensure there is at least one designer assigned to each of the modules that are deemed a priority

This post was also cross posted on CSS3.info.

With the release of Firefox 3 beta today, and the recent release of Safari 3 final joining the beta release of Opera 9.5 kestrel, all the major players bar one have entered the battle field. The Internet Explorer team are still keeping their eight generation browser close to their chest. While Safari 3 has shown its full hand by shipping as a stable release, both Kestrel and Firefox still have time to add features, standards support and polish.

Ignoring IE8, as that would just be guess work, what does this generation of browsers have in store for us at this moment in time? For web designers and developers, standards support is one of the most important details. I'm in the process of comparing these browsers to see how their CSS support stacks up against each other, using the 2007 CSS snapshot as a base. I'm using the current internal build of Opera Kestrel (more or less the same as the last weekly), and the aforementioned Firefox 3 beta and Safari 3 final.

As previously reported, the CSS snapshot includes CSS2.1, CSS3 Selectors, CSS3 Namespaces and CSS3 Colour. While I haven't completed any tests in detail yet, I've done some tests and have a feeling that Opera Kestrel will come out on top. Excluding bugs, Kestrel supports all CSS 2.1 properties and values except one - visibility: collapse. I've not checked the latest changes to this spec however. I'm also not sure if the bugs in the CSS2.1 test suite have been fixed yet. The test suite is huge, so will take a good while to go through, especially for 3 browsers. For CSS3 Colour, I've made a preliminary support chart on CSS3.info. Firefox leads in this regard, with Opera behind due to not supporting the alpha channel on RGB and HSL. Once alpha channel support is added both will get fixed however. The browser support chart for Selectors is in need of an update, but running the selectors test on the same site shows that Opera passes all tests, while Safari and Firefox still have some issues. This isn't strictly accurate as Opera doesn't have ::selection support, and does have some known bugs. There is a more in-depth test suite that I'll go through. It is fairly certain Opera wins out here though. For CSS3 Namespaces, it is pretty much even, with all browsers supporting @namespace, although of the five tests I did find, Safari has one issue, while Firefox and Opera both pass all of the test. Overall I think that each of these browsers has fairly good support for the CSS 2007 snapshot, but Opera should be in pole position for the moment. I could be wrong, and things could change before Firefox and Opera release stable versions, and Safari could even release a stable point release before each vendor releases their final product. Who knows, IE could come and surprise us all as the dark horse in the pack.

After digesting the CSS 2007 snapshot and reading a few blog posts on the subject, I've had a few thoughts on the topic:

• It is refreshing that the W3C is being responsive, and Fantasai is going a great job at the much needed and appreciated outreach. Being more transparent helps a great deal.
• Any feature that has more than one implementation should be listed with a short justification why it isn't included or ready. This could be one justification for the whole module if appropriate, such as Media Queries or multi column layout. It doesn't have to be indepth.
• The same should be true if a module is listed as a recommendation. Again it could be as simple as We found a major issue and are looking at how to resolve it. If properties in a module aren't so interrelated, it is likely that issues will only be present in some properties and not others.
• There should perhaps be suggestions for properties that have some issues but a implementation would be useful with a vendor prefix, so that issues can be ironed out.
• A timeline for when the snapshot should reach recommendation, and when the next snapshot will likely be would be useful too.
• Properties that have at least two implementations, but are not ready should be put on a fast track process for ironing out the issues, with the aim of getting them in the next snapshot, even if their module isn't ready.

The properties I feel that are ready, even though their module may not be include box-sizing, the outline properties, overflow-x and overflow-y and text-shadow (even though WebKit acts differently by not implementing multiple shadows. I'd assume box-shadow should be ready too as it works similarly to text-shadow.

At the Web Directions South conference in Sydney, which I attended, Andy Clarke announced Ocean's CSS Eleven. Now this wasn't really a surprise to me (except the announcement), as I'd been in contact with Andy previously, suggesting the idea of forming some form of designer advisory board to the W3C. I even touched on this topic in a question to Håkon Wium Lie in the interview we had with him on CSS3.info.

I am surprised that no one from CSS3.info was invited, especially with all the work Peter puts in promoting CSS3, and it has been shown that the W3C listens to what the site has to say. I am slightly concerned how many links there are to Apple in the group, but none to the other browsers (one employee, one person that worked on Apple Canada, and one who's company writes and promotes a iPhone only site), unless you count John Hicks who did the Firefox logo and icons for a number of Mac browsers. Having said that, I have no problem with any of the people on the list, and they are all great designers that have promoted web standards, even if one did say Opera did nothing good except media queries during his talk in Sydney .

I do think the group is a good idea (obviously), but there has been some criticism that may need looking into when they have their site in shape. The group seems exclusive at the moment, instead of being a collective mouth piece for designers. I'm sure they'll have a way to gather feedback from designers at large, and the group will turn that feedback into comps and concrete suggestions, that will be reviewed before sending them off to the W3C for comment. I also think there needs to be a open election process after a set period, so the group isn't so self appointed, and people tat prove they are doing good work are appointed, and people that don't have the time to commit or want to leave (if this ever happens) are replaced. Another criticism is the lack of women in the group. This is a topic that often comes up about speaker roosters at conferences. I'd say I'm surprised that women like Veerle are not there, but to be fair these are the people that accepted to join, and we don't know who were asked but didn't have the time to commit to joining such a group, or were not interested for whatever reason. A diversity no one really mentions is the lack of ethnic diversity, and this is also shown with this group. Unlike the amount of women in the industry, apart from maybe people of Asian decent like Cindy Li or Khoi Vinh, there are not a lot of none-white well known designers to suggest. I could be wrong, and it is just that I don't know about them. I certainly hope this situation improves, as web design could do with the diverse styles that art forms like music benefits from with it's large ethnic diversity.

The reasons why I think this is a good step forward, and why I was interested in such a concept to begin with, is that there seems to be a lack of dialogue between those that use the standards (designers) and those that write them. I like to think I'm doing my part to bridge the gap between designers and those that implement the standards. There are a limited amount of designers on the working groups, and not only do most not have time to participate in the spec writing process, but following and understanding implementation issues is beyond the scope of why we need designers involved in the process. The form of communication, with having to search through mailing list histories to see if an issue or idea has been raised is also problematic. We do need a way that designers can get together and decide what they need to have in the spec, and define what a feature needs to be able to do (and look like if appropriate), and then the W3C and browser implementers can take these comps and requirements, and refine them into a implement-able standard. Currently, I assume most specs that deal with presentation are written by people that don't know for sure what designers want, and are not designers themselves. There is a risk that a lot of features will not be of much use to designers, and required features will be missing.

I certainly look forward to seeing CSS Eleven progress, and hopefully can get involved in sure way in the future. I've been soliciting feedback on what features of CSS3 designers want the most for a while, so I'd love to take some of the work that is generated back to Opera, so that we implement what is needed.

While Kestrel is getting ready to spread its wings, we are currently busy adding new features to Core-2 and deep into the QA process. I've already mentioned the CSS3 selectors are done and dusted, but what else is new since the last report? Not forgetting about CSS2.1, we've adding support for whitespace: pre-line;. This edges us ever closer to full CSS2.1 support.

CSS3 support is obviously not as advanced but is moving along with every build. background-size from the backgrounds and borders module is now supported with the -o- prefix. overflow-x and overflow-y from the basic box model module have been supported in builds for a while but not widely reported. This was one of the CSS3 properties that had started to become widely used, due to it being supported in IE, so it was essential to support for site compatibility reasons. It pops up many times in Korean web sites for example. The currentColor keyword has now been added from the colour module. This was already supported in Opera for SVG. This specifies a colour to be the same as the value of the color property or inherits the colour from the parent if no colour is specified. Keeping up Opera's reputation for great keyboard support, nav-index, nav-up, nav-down, nav-left and nav-right have been added from the basic user interface module. This allows control of which element will be targeted next when the user presses the corresponding key. The spec doesn't define what key to use for each, but suggests the direction arrows for keyboard use. This is especially useful when absolute positioning is used and the elements may not be displayed in source order. Also from the basic user interface module, outline-offset has been added to round off our outline support.

As well as these properties and the ones already reported, there has been numerous bug fixes to improve our compatibility with major sites. Hopefully we'll be able to add further CSS3 support as Kestrel matures into a release ready product. We are taking note of what properties developers want and we are assessing if they are ready to be implemented.