CSS3

The annual W3C Technical Plenary / Advisory Committee (TPAC) meetings week took place last month bringing together the CSS Working Group, amongst others, for a series of face to face meetings in Santa Clara, California. Minutes from the meeting have now been made available online and promise progress for a number of CSS3 modules including CSS3 Selectors, Multicolumn Layout, Transitions, Transforms and Animations.

The CSS Working Group just published a Last Call for Comments Working Draft of CSS Backgrounds and Borders Level 3. Please review the draft and send your feedback. We’ll be accepting comments through 17 November 2009. (Note that feature requests are likely to be deferred to CSS4.) The best place for feedback is the CSSWG’s official mailing list [email protected], but we’ll also look at any comments posted (or linked to) here on CSS3.info.

There are a couple issues we’re specifically looking for feedback on:

Rounding vs. Scaling Down

The round option for background-repeat and border-image-repeat resizes images to fit the nearest whole number of tiles, rather than always scaling up or always scaling down. Rounding keeps closer to the intended size and, in the case where one dimension is fixed (e.g. in ‘border-image’), keeps the image closer to the intended aspect ratio. This is almost certainly the best solution for vector images and high-resolution raster images. However, if the given image is a low-resolution raster image, it will require interpolating pixels, which can look bad. See Rounding Extremes for illustrations.

The workaround is to specify a higher-resolution image (e.g. by shrinking from the original with background-size or border-image-width). Possible spec solutions include introducing a separate keyword that always scales down, and changing the algorithm so that we force scaling down whenever interpolation would be required for scaling up. So the options here are

1. Leave the spec as-is (always round to nearest): the workaround is good enough for me.
2. Trigger forced downscaling when interpolation is needed: avoiding interpolation is important to me and I don’t mind that the exact number of tiles is unpredictable and the resulting aspect ratio might skewed a little extra.
3. Default to rounding for round, but I want an extra keyword to force downscaling in all cases (including vector images) because […].
4. Something else?

Please comment on what you prefer and why. (The more specific you can be “for example, this image that I would want to use […]”, the easier it will be for us to understand your point.)

box-break naming

The previous draft included two properties for controlling behavior at box breaks (line breaks / column breaks / page breaks): border-break for controlling whether the border is drawn at the break, and background-break for controlling whether the background is drawn for each box individually or for the whole element as if it were broken after painting.

Hyatt suggested merging the two, so the current draft has a single box-break property instead. The two values mean, basically, “render backgrounds and borders for this box, and then slice it up” and “break the box and then render backgrounds and borders for each box individually”. The value names aren’t particularly clear, however, so we were wondering if anyone has better ideas.

Conclusion

So take a look at the new draft and send us your comments! This is your last chance to give feedback on this module: if all goes well, we’ll be publishing the Candidate Recommendation in time for Christmas, and given the state of experimental implementations right now, I expect things to move rapidly from there.

The W3C have released an updated working draft of the CSSOM View Module, edited by Anne van Kesteren.

Many of the features defined in the CSSOM View Module have been supported by most browsers for a long period of time, with many tracing their routes back to Microsoft’s Internet Explorer. The goal of this specification is therefore not to reinvent the wheel, but rather to define these features in such a way that they can be implemented by all browsers in an identical way.

The W3C today announced the release of two new working drafts; the flexible box layout module and images values module.

Perhaps foreshadowed by Google’s adoption of HTML 5, Jeffrey Zeldman pointed out late last week; the future of XHTML 2 is no more. Obviously the selectors we use in CSS 3 depend on the underlying markup we work with, so this news is very interesting and we think timely. As CSS 3 support inches forward with each browser release and as JavaScript libraries supplement poor browser behavior, the need for web developers and enthusiasts to be able to focus their attention has become a paramount concern.

News about developments in CSS 3 is hard to come by at the moment, so please forgive the slow rate of updates on the site in the last month. I attended the @media conference here in London last week and news on progress in CSS was noticeable by its absence, when even HTML 5 had its own session.

I see that Bert Bos has delivered a couple of presentations on the Template (formerly ‘Advanced’) Layout Module, but I can’t find slides of them anywhere. If anyone attended the talks and can send us copies, do please get in touch.

Other than that, the only news is that the CSS WG have released their list of expected module deliverables; the modules listed in the 2007 snapshot along with Media Queries look set to be Recommendations shortly, with many others to take on Candidate Recommendation status.

And that’s it. Sorry there isn’t more, or that it isn’t more exciting. I’m aiming to put together a load of new examples soon, so that should be more interesting!

Update: As mentioned in a comment below, no sooner do I say there’s not much going on than David Baron announces that the remaining CSS3 selectors have been implemented in a build of Mozilla (which will probably be seen in Firefox 3.1), and Media Queries are set to follow. That’s good news.

Over at Design Shack they’re four posts into the five-post Introduction to CSS3, which covers Borders, Text Effects, the User Interface and (coming soon) Multiple Columns. A nice intro to the subject if our own examples are too complicated for you :p

The new owners of the Fonts and Web Fonts modules, Jason Cranford Teague and John Daggett, say that only about 20% of the Web Fonts module is required for CSS (it is currently part of the SVG charter), and propose simplifying it before merging with the Fonts module. They hope to have a working draft of the new spec in August.

The closing date for letting the W3C know your priorities for CSS3 is Monday, March 10th. If you want to help shape the future of CSS, get over to webstandards.org and leave a comment now.

Is there ever a time when you wish CSS allowed you to apply style in ways that either are not currently possible, or require hacks and extra markup to make it possible? Well now is the chance to let the working group know exactly what you want. Bruce Lawson is collecting your feedback on the WaSP site. Go there and leave a comment outlining what effects you’d like to achieve. You can also leave feedback on the CSS3 Soapbox.

Remember that the Working Group want examples of what you are trying to achieve, so that they know if current proposals fit that need, or they can think about adding new functionality. Also state why you want to be able to do that, if it isn’t obvious. They are not looking for feedback on syntax, so just leaving a list of new properties you want added won’t be helpful. Also try to check the latest draft modules to see if your proposal is already possible. Things like rounded corners (border-radius) and striped tables (tr:nth-of-type(odd); or nth-child(even); etc.) are already possible. There may be things that you want to be able to do with a property that isn’t possible in the current spec (such as being able to have an inverted rounded corner using border-radius for an example off the top of my head). If this is the case then the suggestion will be very much worthwhile.

Also remember that there is no guarantee that things you suggest will be added to the spec, even if it makes sense, and is technically realistic to achieve.

We at CSS3.info are planning to have a wiki (or similar system) to collate feedback on CSS3 in one place, which can be referenced easier than a mailing list. We will include the most popular suggestions from the WaSP post (with full attribution) when the wiki is in place, and open it up to the public to edit. If suggestions get added to the spec, we can also include the syntax that will achieve that suggestion, and eventually a demo that will produce the same result, once it gets implemented.

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