A lot of exciting things happened over the course of the last two months in the standards world. This column took another break last month, because yours truly had to work hard on the launch of a very promising project we had in the works for a long time – WebPlatform.org. What is it? The section on it below should answer many of your questions.
The week of 29 October to 2 November was TPAC week: W3C’s annual standards-fest where every Working Group gets together for several face-to-face meetings. Many resolutions are made during TPAC and this was no exception. I was in the CSS WG meetings, so I will cover that in this roundup and the resolutions of other WGs in the next one – after the minutes have been published. But TPAC is not all work and no play – standards geeks sure know how to party and we put that knowledge to good use!
It all started a few years ago, when Doug Schepers of W3C noticed how fragmented web development resources were. Every company was working on its own developer website, and developers had to use multiple resources to get all the pieces of the puzzle. Schepers got together with many of the web's big players – Adobe, Apple, Facebook, Google, HP, Microsoft, Nokia, Mozilla, Opera – and WebPlatform.org was conceived. About a year later, this October, we launched an alpha version to the world.
It’s still incomplete and has many bugs, but we wanted to launch early and work in the open, with the community, not hidden away from it. This is where you come in. WebPlatform.org needs your help to achieve its vision and to become a vendor-neutral, one-stop resource for everything related to the open web stack of technologies, by developers, for developers.
Its scope is not just limited to W3C technologies, but includes almost every open web standard. The main things currently out of scope are server-side technologies and script libraries. We might include an introduction on these, but we do not plan to cover them extensively.
Test The Web Forward – Paris 2012
Test The Web Forward (TTWF) is an event dedicated to writing tests for the various W3C specifications. Testing is very important, because a specification cannot move forward without a complete test suite for every feature it describes. The purpose of these tests is not primarily to test conformance – although they are often used that way – but to verify the implementability of the spec they are written for.
One of the reasons W3C specifications take a long time to reach Recommendation status is the lack of enough tests. TTWF is a series of events all over the world that are trying to rectify this by crowdsourcing test authoring to the community, while at the same time educating developers about testing, knowledge that can be useful in their own unit tests as well. So far they have been very successful, with the most recent one in Paris (26-27 October) producing a total of 404 tests! If this sounds interesting, keep an eye out for the next one!
W3C Developer Relations
W3C Developer Relations (or DevRel for short) is a new W3C activity – of which yours truly is a part – that focuses on connecting the W3C and developers. We've just started looking what our larger activities will be, beyond W3Conf and WebPlatform.org, and we're looking at working more closely with other devrel teams. Stay tuned, because I expect many cool initiatives to come out of this. We're on Twitter at @W3Cdev.
HTML5 to reach Recommendation status by 2014
The HTML WG has devised a plan to formally finalise HTML5 by 2014. However, this is a tough goal and it doesn’t come without casualties. Some unstable and/or underspecified features will be moved to HTML 5.1. Others will become a separate specification that will advance at its own pace (APIs are good candidates for this). The new HTML 5.1 draft should reach Recommendation (REC) status by 2016, which is still a far cry from the 2022 that was once estimated. Hopefully, HTML5 reaching REC should speed up its adoption by some groups, especially the dreaded Enterprise.
FPWD of Web Cryptography API
FPWD of Filter Effects 1.0
Remember that exciting Adobe proposal about commonly needed SVG filters with simple CSS-only syntax? It’s now a Working Draft, which means it has a higher chance of browsers implementing it as it iterates and stabilises.
CSS Image Values 4
In the last instalment of this series I described conic gradients that finally made their way into Image Values 4, still an Editor’s Draft (ED) at the time. Now it has been published as a Working Draft (WD) and includes a couple more interesting features.
Two positions per colour stop
Remember stripes with CSS gradients? They usually involve a bit of repetition, as every colour needs to be included in two colour stops. Image Values 4 will make this a tad easier, by enabling you to specify two colour stop positions as syntactic sugar for having two adjacent colour stops with the same colour and different positions. For example:
linear-gradient(white 25%, gray 25% 50%, black 50%)
would be expanded to:
linear-gradient(white 25%, gray 25%, gray 50%, black 50%)
Remember when you wanted to create a pixelated effect (like the background of the Fronteers website), but you had to manually resize the image in Photoshop to avoid blurriness? If this gets implemented, it will only take one line of CSS!
This is not brand new, but it’s new to me and I suspect to many of you as well. I discovered it during Anne Van Kesteren’s breakout session at TPAC. Sir Tim Berners-Lee was there, so I was a bit too starstruck to pay enough attention, but I looked it up afterwards and it looks sweeter than a briouat bil luz. Not only does it define more forgiving parsing, but also an API to handle read/write of URL parameters much more easily (currently we can only get the entire location.search and parse it manually).
Speech API proposal
Google published an interesting proposal for a Speech API through the eponymous Community Group. Don’t let the name mislead you; this has little to do with accessibility. It’s about enabling web applications to synthesise and recognise voice. Remember the x-webkit-speech attribute? Think bigger. Much, much bigger. The possibilities are endless if something like this goes through!
TPAC 2012 Special — CSS WG
The CSS WG held three days of meetings at this year’s TPAC, one more day than most other WGs. Too many issues to discuss, too little time. As usual with Working Group f2f meetings, most resolutions are not of direct interest to authors, as they pertain to rare edge cases. However, many of them are quite fascinating.
Non-animatable properties will animate in one discrete step
This is a resolution I’m especially excited about, since I created the test case that proved it was necessary. In a nutshell, currently when you use non-animatable properties in @keyframes, they get completely ignored, even when they don’t change. The caveat is that this also applies to the longhand properties in shorthands. So, when you are animating a border from 0 solid black to 20px solid black, it will get expanded to border-width: 20px, border-style: solid and border-color: black (in fact, it will be expanded to their longhands, since these are also shorthands). However, border-style is not animatable, so it will get ignored. If you haven’t set a border-style value in other rules, its initial will be used, which is none. Thus, no border will ever be shown, which can be incredibly confusing. The resolution was that such properties will now be animatable in one discrete step, which will occur at 50% of the timing function. This will not be carried over to transitions, as it would break existing cases where transition-property: all was used (which is exactly what happens every time you write something like transition: 1s;).
Text decoration as a separate spec
Those of you that have taken a look at the CSS Text Level 3 module might have noticed that it’s a very large spec, defining both Internationalisation characteristics and text decoration features (text-shadow, text-decoration and so on). Having specs that are too broad is not good: they require more editorial effort and are slower to advance. Its editor, Fantasai (Elika Etemad) saw that and decided to split it into two modules: Text and Text Decoration. In the recent TPAC meeting, the CSS WG accepted her reasoning and approved the split.
A while ago, the CSS WG chairs asked every member company and every invited expert in the group to rank the 50-something in-progress specs we have as one of the following: VSI (Very Significant Interest), SI (Significant Interest), LI (Low Interest) or NI (No Interest). The aggregated results were recently posted to the public. In general, it looks like the results correlate with author interest as well, although sadly all Level 4 specs are near the bottom.
Potential improvements to CSS Box model
At first, there was no vertical centring. Then we got display: inline-block, and we could make it work in some cases with some trickery. Later, we got table display modes, but that required too many elements to work and imposed a lot of restrictions. Long after that, we got Flexbox, but that also wasn't perfect for this, as flex elements behave in different ways than we often want as well. After more than a decade of no perfect solution for this incredibly common problem, the CSS WG finally started discussing the idea of offering vertical centring without any special layout mode. Discussions are still at a very early stage, but the mere idea fills me with excitement and hope.
Toggleable states in CSS
Have you ever heard of the HTML5 <details> element? It enables you to easily make collapsable widgets, with pure HTML. The CSS WG discussed this, at first to see if any pseudo-classes needed to be added to CSS to target its two states (the answer was no, just use an [open] attribute selector). During the discussion, we noticed that other elements could benefit from toggleability. Therefore, it’s very likely that such a feature will be added in CSS and will work for every element, not just <details>. Regarding the syntax, there is already a rough proposal by Tab Atkins of Google, but it will probably change a lot – if not completely – before it makes its way into any browsers.
CSS Display Module Level 3
In the spirit of modularising specs and keeping each short, Tab Atkins thought it was a good idea to split the display property into a separate spec, adding a few new features in the process. According to the draft, the property now becomes a shorthand for display-inside (how the contents are laid out), display-outside (how it behaves relative to the elements around it), display-box (whether it generates a box) and display-extras (currently to toggle list marker generation). This creates many potential combinations that just weren't possible in the past. After strenuous discussion, the CSS WG agreed that this spec is a good idea and it should move forward.
CSS Cascade Module Level 3
Cascading and inheritance is a CSS Module that hasn't enjoyed the attention other CSS modules have gotten. Its last update was in 2005, no less than seven (!) years ago. In this f2f meeting, the CSS WG decided to handle editorship over to the prolific duo of CSS: Tab and fantasai. They have some very interesting ideas about new features that could be included, like an all property that will accept the values inherit and initial only. This is incredibly useful for cases where you want to reset every property in a widget to its initial value, to avoid unwanted interactions from the surrounding styling.
Words: Lea Verou
Lea works as a developer advocate for the W3C. She has a long-standing passion for open web standards, which she fulfills by researching new ways to use them, blogging, speaking, writing, and coding popular open source projects to help fellow developers.