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 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.
Microsoft today offered developers an early glimpse of Internet Explorer 9 (IE9) at their 2009 Professional Developers Conference.
Although only at an early stage of development, the IE9 team already looks to have made some impressive leaps forward in terms of web standards support, particularly with regard to CSS3 selectors which, by the looks of the image below (taken from the IE blog), IE9 appears to score an impressive 574 out of 578 in our CSS3 selectors test, a vast improvement over IE8 which scored only 330/578.
IE9 also looks set to boast support for CSS3 border-radius, an improved scoring in the Acid 3 test (if only slightly) and support for HTML5. You can read the full announcement on the IE blog here and we’ll bring you further announcements on the subject as more information becomes available.
Adobe today released a public beta of AIR 2, available for download from their Adobe Labs website, with the final release expected somewhere in the first half of 2010.
Adobe AIR 2 offers a number of improvements and advantages over its predecessor, including advanced support for CSS3 & HTML5 thanks to an updated version of the Webkit browser engine – in fact the same version as used to power Safari 4.0.3. This means developers can now create desktop apps with advanced support for CSS3 modules, notably 2D transformations, transitions, animations, gradients, zoom and Webkit CSS selectors.
Adobe AIR 2 provides end users with exceptional application experiences while giving developers the easiest and most powerful way to develop desktop applications across multiple platforms (Mac, Windows, and Linux). You can find out more about the release of the AIR 2 beta here.
This development will undoubtedly lead to an increased usage of CSS3, which has already gained widespread use in mobile application development this year.
To coincide with Web 2.0 Expo in New York, Opera is organising a free Standards.Next event on the topic of CSS3 the following Friday 20th November, at the Time–Life Building. This space has been generously donated to us by Time & Life.
The Standards.Next concept is to showcase, teach and raise awareness of future Web standards-based technologies. After two events in London featuring HTML5 and Accessibility, our third event is the first time we’ve brought the event State side. With NYC being a design-centric town, CSS3 was the perfect topic.
Font Dragr is a HTML5/CSS3 powered web app for testing custom web fonts. The app allows you to drag and drop your truetype (ttf), opentype (otf), scalable vector graphics (svg) or Web Open Font Format (WOFF) fonts into the webpage for an instant preview of how the font will be rendered in the browser, you can even edit the example text.
Mozilla has joined a growing list of organizations to throw their support behind the Web Open Font Format (WOFF) and will support the embedding of WOFF fonts via @font-face from Firefox 3.6 onwards, or if you’re a developer and want to play around with this now, just download a recent nightly build or beta.
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.