In the first of a regular series of reports, Lea Verou summarises the latest need-to-know developments in the fast-moving world of the Working Groups …
May 2012 brought many exciting developments in web standards, across a number of different Working Groups. Here, in the first of a regular series of reports, I’ll sum up the hottest topics and emerging trends every professional web designer needs to know about. If any of the concepts seem unfamiliar, you can might want to begin by reading the 8 biggest web standards myths, debunked. Otherwise, let’s get started!
Blending modes and filters are coming to CSS
Ever wanted to blur an HTML element? Greyscale its contents? Use Photoshop-style blending modes on it, like “Multiply”? There are two new proposals that do exactly this:
These are not entirely new concepts, they have been possible in SVG for a long time. However, these new specifications bring those effects to HTML content as well. In addition, they are introducing a couple of simple shortcuts, that eliminate the need of linking to an SVG file that contains the effects. For example, to blur an element, you simply do:
Filters also solve the common problem with CSS box-shadows which don’t follow the transparency of the element, but are always rectangular (see image). CSS filters can produce true drop shadows that fully follow the form of the element, accounting for non-solid borders, semi-transparent fills, pseudo-elements etc. You can play with a dabblet comparing the differences here.
Blending modes are equally simple to apply:
There are going to be ways to selectively apply blending modes to parts of the element, such as only the background or shadows, but the syntax for this is still under discussion.
Filters are already supported by Chrome (behind a -webkit- prefix), so you can experiment with them all you want. Blending modes are newer and have no implementations yet. However, once they get a few implementations you can start using them immediately, as they both degrade quite gracefully.
Both specs are developed in the FX task force (FX TF), which is a joint effort between theCSS WG and the SVG WG. The FX TF focuses on developing new specifications that apply to both CSS and SVG as well as merging and simplifying existing technologies that could apply to both (such as transforms).
The responsive images saga
“Responsive images” is a term used to describe a number of approaches to conditionally load different image files on an <img>, based on the capabilities of the client (eg screen size, pixel density etc).
Lately, there has been a lot of discussion around standardising responsive images. After a misunderstanding in the WHATWG mailing list, a group of developers formed a W3C Community Group to discuss the issue. After a lot of back and forth, they decided that the best solution would be a
<picture> element, containing one or more <source> elements, as well as an optional fallback (eg an <img>). One of the biggest benefits of this approach is consistency, as it’s on par with other HTML5 media elements, such as <video> and <audio>. According to most authors, it’s also a more elegant and easy to understand syntax.
Unfortunately, it turned out that, despite the aforementioned benefits, their proposed solution was harder to implement as it conflicts with the work performed by the lookahead pre-parser, a technique employed by every rendering engine to download assets faster, before even proper parsing of the content. In addition, it was advocated that media queries are not the best way to select which assets to load. For example, if we have an iPhone 4 Retina display with a high pixel density, but said iPhone is currently on a data roaming internet connection that costs €3/MB, do we load high- or low-res images? Media queries won’t help here and as someone who uses data roaming a lot, I don’t think such use cases are negligible.
For these reasons, WHATWG settled on a srcset attribute instead. A lot of author outragefollowed that news, but at the time of writing, WHATWG is still reluctant to reverse their decision. Furthermore, rumours are circulating that Apple has already implemented srcset in WebKit, pushing WHATWG towards it.
CSS Alignment module
In the past few years, it became clear that CSS layout was lacking. Floats and CSS tables were not built for laying out web applications. To deal with this, the CSS WG authored a number of different layout modules, such as Flexbox and Grid Layout.
These new modules are finally on par with the layout managers traditionally used in native applications. However, fantasai noticed that they each introduced different mental models and syntax for alignment, even though this could be shared across all layout-related CSS modules. To rectify this, she started a new draft that attempts to merge all these different models into one: CSS Box Alignment Module Level 3. It’s still at a very early stage, but it’s showing a lot of promise.
Flexbox is on its way to Last Call, a milestone that will also incorporate the new alignment properties.
CSS prefixes, again
A few weeks ago, Opera’s leaked decision to actually implement some
-webkit- featuresstirred the CSS prefixes drama again. The issue is multi-faceted and it could even be said that it’s one of the worse situations the CSS WG has ever faced. The main problem is that every proposed solution suffers from at least two of the following four problems:
- Does not allow the CSS WG to get enough author feedback on experimental features (eg constraining experimental features only in non-stable browser builds)
- Does not allow the CSS WG to change the features because any change will break too many existing websites (the current situation)
- Does not allow authors to target specific implementations, which is a problem since experimental implementations can (and should) be vastly different (dropping the prefixes falls in this category)
- If authors are allowed to target specific implementations in an opt-in fashion, they don’t handle it responsibly, turning the system into a popularity contest (the current situation).
At the moment, it seems almost impossible to find a holy grail solution that will address all of the above. Florian Rivoal from Opera took a shot at it, with a proposal that gained some traction, as it almost eliminates both #3 and #4. Unfortunately, it still suffers from issue #2, so it was rejected.