Over the course of the last two weeks, the W3C CSS Working Group have issued three updated CSS3 specifications. The first sees the CSS3 Backgrounds and Borders module return to candidate recommendation, with the second and third providing updated working drafts of the CSS3 Text and CSS3 Image Values and Replaced Content modules respectively.
The working group also introduced a new module, CSS3 Writing Modes, just over 2 weeks ago on the 1st February. This recent flurry of activity represents the first major updates to the CSS3 specifications since the CSS3 Color module was released as a proposed recommendation in October last year.
Let’s take a look at what’s new.
The CSS Working Group met in Oslo last month for three days of face to face meetings.
The minutes, available on the CSS Working Group’s blog, reveal discussions around CSS2.1, several CSS3 modules, a rough draft of the Working Group’s priorities for 2010 and even taking Microsoft to task over their controversial test results published earlier this year.
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
border-image-repeatresizes 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
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
- Leave the spec as-is (always round to nearest): the workaround is good enough for me.
- 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.
- Default to rounding for
round, but I want an extra keyword to force downscaling in all cases (including vector images) because [...].
- 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.)
The previous draft included two properties for controlling behavior at box breaks (line breaks / column breaks / page breaks):
border-breakfor controlling whether the border is drawn at the break, and
background-breakfor 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-breakproperty 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.
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.
One aspect of CSS3 that hasn’t received a lot of attention so far is the Flexible Box Layout module. Already implemented in the Gecko and WebKit engines, in this alternative box model:
“… the children of a box are laid out either horizontally or vertically, and unused space can be assigned to a particular child or distributed among the children by assignment of ‘flex’ to the children that should expand.”
It’s probably easier if I show you how this works. NB: you’ll need to be using Firefox, Safari or Chrome (or a variant thereof) to see the demos; and if you’re reading this in a feed reader, you’ll need to visit the original post to see them.
After many man-hours of work, Opera has unleashed Opera 10. This release contains the Opera Presto 2.2 rendering engine. The two main features in regards to CSS3 are Web Fonts and full support for the CSS 3 Color specification.
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.