CSS3

The CSS3 Selectors module and CSS3 Namespaces module have both been released as official W3C recommendations, becoming the second and third CSS3 modules, respectively, to reach the end of the development cycle, following on from the release of the CSS3 Color module as a W3C recommendation earlier this year.

Hats off to the CSS Working Group, it must have been a busy few weeks. Not only have they released several updated specifications, most notably the long awaited publication of the CSS2.1 specification as an official W3C recommendation, but also introduced a major redesign of their home page.

The release of CSS2.1 as an official recommendation also paved the way for the CSS3 Color module to advance to the recommendation stage, becoming the first CSS3 specification to be released as an official W3C Recommendation.

Posting on behalf of Tab Atkins about an open spec issue:

I’ve been pretty adamant for some time that gradients should use the math-y interpretation of angles, where 0deg is East and 90deg is North. In addition to matching what you learn in school about polar coordinates, it matches what tools like Photoshop expose. Other members of the WG, though, have been equally adamant that we should more closely match existing language conventions, particularly that bigger angles mean clockwise rotation.

The strength of my conviction has eroded over time. It really is true that every other use of angles uses them to represent clockwise rotations. In SVG, angles are present in transforms and the glyph-orientation properties, while in CSS they’re present in transforms, image-orientation, and the azimuth and elevation aural properties. In all of them (save elevation, which rotates in a different axis), the rotation is clockwise.

The W3C CSS Working Group have introduced a new module to CSS3, the CSS3 Grid Layout module, as well as released two further updated specifications, for the CSS3 Multi-column Layout and CSS3 Text modules.

Let’s take a closer look at what’s new.

The W3C CSS Working Group have released two further updated working draft specifications for CSS3.

The first, released on 11 March, sees a major overhaul of the CSS3 Flexible Box Layout module. The second, released on 24 March, brings several enhancements to the CSS3 Fonts module.

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.

Following on from the W3C TPAC 2009, held back in November, CSS3 Selectors was officially advanced to Proposed Recommendation by the W3C Director earlier this week.

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.