Posts Tagged ‘csswg’
As you may (or may not) know, I’m an Invited Expert on the CSS Working Group at W3C. Mostly I talk about specs. But today, I’m going to talk about testing.
W3C is working on test suites for the CSS specs, and I wanted us to have more web authors involved. Many of you have been frustrated with the inconsistent levels of CSS support across browsers, and I believe collaborative testing is one of the major ways we can improve the situation.
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.
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 (
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.