We know the frustration all too well… The goal is to build websites and web applications that are cross-browser compatible and provide a similar experience across the board. Unfortunately, when new CSS functionality comes out, we get stuck between having to wait for browsers to adopt it in unison, which can take a few years or hacking our way through the differences. It shouldn’t have to be this way…
Data obtained from W3C as of May 2016: http://www.w3schools.com/browsers/browsers_stats.asp
What’s the Current Climate?
Taking a look at browser statistics, the climate has shifted towards the modern browsers with 74% of users on Chrome, but there’s still a decent chunk of users on IE (about 5.7% – the majority of which are now using IE11 or above).
That’s great news but even so, there are still considerable browser differences we must continue accounting for.
So With That… What is Houdini?
Houdini is a new W3C Task Force that consists of engineers from Mozilla, Apple, Opera, Microsoft, HP, IBM, LG, Intel and Google working together to expose certain parts of the CSS engine to web developers.
The task force is working on a collection of drafts to propose to W3C to become web standards.
How Can Houdini Help?
The task force plans to help by introducing a new set of APIs that will, for the first time, give developers the power to extend CSS itself, and the tools to hook into the styling and layout process of a browser’s rendering engine. This will cut down on the length of time between when new CSS functionality is proposed and when we developers can use them (functional across all browsers).
Houdini’s Proposed API List
CSS Parser API
Currently not written but the goal of this API is to extend the CSS Parser and tell it about new constructs.
Examples:
- New media rules
- New pseudo-classes
- Nesting
- @extends
- @apply
Once the parser knows about these new constructs, it can put them in the right place in the CSSOM, instead of just discarding them (as seen with some strikethroughs in the Inspector tool for unrecognized code). How amazing would it be to nest CSS rules without a preprocessor? Or add new media rules, pseudo classes and more on the fly? Does anyone hear the freedom bell ringing?
CSS Properties and Values API
CSS already has some custom properties but this API takes custom properties a step further and makes them more useful by adding types. A big benefit to adding types is that it will allow developers to transition and animate custom properties (not currently possible today). Another promising feature of this API is the ability to register an “apply hook,” which gives developers a way to modify the final value of a custom property on elements after the cascade step has completed, which could be a very useful feature for polyfills.
CSS Typed OM
CSS Typed OM is version 2 of the current CSSOM. Its goal is to solve a lot of the problems with the current model and include features added by the new CSS Parsing API and CSS Properties and Values API. Since CSS is only capable of cascading through the DOM, that means CSS can only be applied to elements that have semantic meaning. Many times, a designer wants to create or manipulate a visual element for which there is no semantic hook. Because CSS can not query, freely traverse, nor manipulate the DOM, we are forced to add non-semantic hooks to the HTML.
CSS Layout API
The CSS Layout API enables developers to write their own layout modules. And by “layout module,” I mean anything that can be passed to the CSS display property. This will give developers, for the first time, a way to lay out that is as performant as native layout modules such as display: flex and display: table. The CSS Layout API works by giving developers a registerLayout method that accepts a layout name (later used in CSS) and a JavaScript class that includes all of the layout logic.
CSS Paint API
Similar to the Layout API, the Paint API provides a registerPaint method. Developers can use the paint() function in CSS anywhere that a CSS image is expected and pass in the name that was registered. It provides a registerPaint method that operates just like the registerLayout method. Developers can then use the paint() function in CSS anywhere that a CSS image is expected and pass in the name that was registered.
Worklets
Many of the specs mentioned above require additional coding to add the enhanced functionality; this code would be placed in worklet scripts. Worklets are similar to web workers; they allow you to import script files and run JavaScript code that (1) can be invoked at various points in the rendering pipeline and (2) is independent of the main thread. Worklet scripts restrict what types of operations you can do, which is key to ensuring high performance.
Composited Scrolling and Animation
This is one of the more well-known and highly anticipated Houdini features. Soon, this API will allow developers to run logic in a compositor worklet, off the main thread, with support to modify a limited subset of a DOM element’s properties. This will enable developers to create highly performant scroll- and input-based animations, such as sticky scroll headers and parallax effects.
Is This Usable… Now?
The APIs are still being worked on but they’re closer to completion than we might think. Very soon we’ll be able to get excited about learning this new technology and being able to use the latest on our websites/web applications in a shorter time frame.
What Can We Do?
Houdini needs to hear from us, developers in the trenches, dealing with the pain of these CSS bugs or shortcomings on a daily basis. We can contribute to use cases or developing these drafts to help Houdini solve the ongoing issues we’ve had to face, leading to a more peaceful/pleasurable web experience.
Make sure to check out the current drafts on GitHub to stay updated:
https://github.com/w3c/css-houdini-drafts/wiki
