This is a page from the Cascading Style Sheets Working Group Blog. Some other places to find information are the “current work” page, the www-style mailing list, the Future of CSS syndicator, and the issue list on Github.
Do you want to know how the CSS WG works? Fantasai has written about:csswg, An Inside View of the CSS Working Group at W3C.
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 www-style@w3.org, but we’ll also look at any comments posted (or
linked to) from the cross-post on CSS3.info.
There are a couple issues we’re specifically looking for feedback on:
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
round
, but I want an extra keyword to force downscaling in all cases (including vector images) because […].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-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.
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.