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
Generated content via the
contentproperty has been available since CSS2. However this was only available using the
:afterpseudo-classes. In CSS3 this support has been expanded to be useable on any element, without needing to use these pseudo-classes. Unfortunately this only works in Opera 9 (and above) at the time of writing.
I use this capability in my iTunes interface demo that I’m currently building to show off how powerful current and future web standards are for building application interfaces. This currently isn’t finished yet, and is very buggy (no min-width, missing features, no scrolling on the source list, content jumps, and no actual music support to name but a few). but you can take a sneak peak here. Due to MyOpera hot linking restrictions, you’ll need to press enter (or return) in the URL field to reload the page. This currently only works in Opera Kestrel due to missing standards support in other browsers, so download the latest weekly before trying it out.
contentproperty is used here so that the buttons and the playing column on the song list can contain their text labels. This is important for accessibility and if the page is styled differently and the design requires text instead of icons. The text is then set to empty using
content: "";for the relevant element. I’m sure there is a more cross-browser way of doing this, but the site is a demo so advanced properties and technologies were chosen to showcase them. To complete the buttons, and other parts of the interface, a SVG background was used. I plan to add
border-radiusto make the view buttons, and the head and footer of the interface have rounded corners. The screen needs to use SVG as the border uses a gradient to add the perception of depth. I suppose a border image can be used, but I like this approach. Other CSS3 properties used include
overflow-y(The Genre, Artist and Album lists, and eventually the song list table),
text-shadow(many of the headings), and CSS3 selectors (the song list and the button buttons). Other advanced technology used include SVG and HTML5 (
This is a sponsored post for my employer, Onetomarket, I don’t usually do sponsored posts here, but since this could ease my work life a bit :) , I’ll make an exception.
- Are a good PHP / MySQL developer.
- Can develop an application based on different API’s on your own.
- Have ideas on how to improve stuff and can explain them to us.
- Would like to work with a team of young and enthusiastic internet professionals.
Then maybe you should join us in our office in Arnhem, the Netherlands or in Barcelona, Spain. Mail me at joost ” at ” joostdevalk dot nl, and I’ll set you up for a meeting!
To create a coherent collection of blog discussion about CSS3 and the future of CSS, the CSSWG and the css3.info team have teamed up to create a W3C-hosted aggregate feed, The Future of Style, and an associated css3.info-hosted open community blog, the CSS3 Soapbox.
We’re starting off The Future of Style by pulling in the CSS Working Group Blog, css3.info, and the CSS3 Soapbox. If you have a post you want to add to this feed, post a link (or the whole thing) on the CSS3 Soapbox. If you own a blog with frequent posts about the future of CSS, and want to be added to The Future of Style, contact fantasai.
The CSS3 Soapbox is meant to give you as a developer, designer or whatever, a voice in css development. This feed will be read by all those involved in CSS development, so you can get your message across easily.
We want you to join the conversation!
With the latest weekly of Opera, Opera will support the HSL colour unit. With HSL added, there are only three units missing, HSLA, RGBA and flavor. I don’t really understand flavor, or why it would be useful and no browser currently supports it. I’d suspect now that Opera Kestrel supports RGB and HSL, that the two colour models with added alpha channel support will both be added at the same time. I can’t confirm when these will be added yet however. You can test out support for this here.
I’m working on a support chart for the colour module, that just needs testing to be finalised in IE, as I currently don’t have access to IE7. This should be added to the Module Status page shortly.
We’re busy here at css3.info! Our interview with H&kon was cool of course, but then Opera 9.5 was released and we had to update and add quite a few pages… Because all these pages were still static html, that was quite a bit of work. Tonight I took the time to move all of them into WordPress, and after I’d done that, I’ve refined the search function and results a bit, so it now shows the pages in the searches as well!
We’ll probably be adding new preview pages in the coming days, I’ve already updated the existing ones which Opera 9.5 supports now (cool, cool stuff, you should really have a look at it).
Ow and because of the many complaints about it, I removed the text-shadow from the text in the menu tabs.
You’ve probably seen the ad for them on the right hand side by now if you’ve visited this site before, but we thought it would be good to introduce them in a post as well: a warm welcome to FreshBooks!
FreshBooks let’s you send out invoices through a great online interface, has a nice API, automatically accept all sorts of payments, etc. etc. etc.! I seriously suggest checking out their tools if you do a lot of invoicing, especially as they are NOT expensive.
When you’re at it, check out the great design of their site… It’s one of the best looking commercial sites I’ve seen in a while.
Now that got your attention, didn’t it? You’ve probably never seen a site where Safari has a market share of 84%… Well neither had I. Until I looked at the browser stats for this site… I just had to share it with you all:
As liquidat points out quite correctly, it is NOT Opera that is the first to support all the tests in our CSS Selectors test. Those bragging rights go to Konqueror, as we pointed out in January already. Release 3.5.6 of KHTML was the first to support all the tests, not any other browser, sorry David :) .
We, the CSS3.info team, are very very proud to see our Selectors Test being used as the de facto test of selectors compatibility though, and we hope that other browser projects will be using it too!
While I’m at it, please remember that our preview section is only a showcase of css3 properties that are currently implemented in any browser. If any browser were to support all the things in that section, this does not constitute “full css3 support”, as there is no such thing yet. This also means that it could be that we are missing features in that section that are currently implemented in a browser, if that’s true, please drop us a line!
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.
(Besides companies allocating more man hours to working on css specs. ;)
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.
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.