Have you ever thought about the amount of work CSS does? You change a single attribute and suddenly your entire website appears in a different layout. It’s kind of magic in that regard (can you tell where I am going with this?!). So far, we – the community of web developers – have only been able to witness and observe the magic. What if we want to come up with our own magic tricks and perform them? What if we want to become the magician? Enter Houdini!
The Houdini task force consists of engineers from Mozilla, Apple, Opera, Microsoft, HP, 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 with the goal to get them accepted by the W3C to become actual web standards. They set themselves a few high-level goals, turned them into specification drafts which in turn gave birth to a set of supporting, lower-level specification drafts. The combination of these drafts is what is usually meant when someone is talking about “Houdini”. At the time of writing, the list of drafts is still incomplete and some of the drafts are mere placeholders. That’s how early in development of Houdini we are.
Disclaimer: I want to give a quick overview of the Houdini drafts so you have an idea of what kind of problems Houdini tries to tackle. As far as the current *state of the specs allow, I’ll try to give code examples, as well. Keeping that *in mind, please be aware that all of these specs are *drafts and very *volatile. There’s no guarantee that these code samples are even remotely *correct in the future or that any of these drafts become reality at all.
The specifications
Worklets (spec)
Worklets by themselves are not really useful. They are a concept introduced to make many of the later drafts possible. If you thought of Web Workers when you read “worklet”, you are not wrong. They have a lot of conceptual overlap. So why a new thing when we already have workers? Houdini’s goal is to expose new APIs to allow web developers to hook up their own code into the CSS engine and the surrounding systems. It’s probably not unrealistic to assume that some of these code fragments will have to be run every. single. frame. Some of them have to by definition. Quoting the Web Worker spec:
Workers […] are relatively heavy-weight, and are not intended to be used in large numbers. For example, it would be inappropriate to launch one worker for each pixel of a four megapixel image.
That means web workers are not viable for the things Houdini plans to do. Therefore, worklets were invented. Worklets make use of ES2015 classes as nice way to define a collection of methods, the signatures of which are predefined by the type of the worklet. They are light-weight and short-lived.
Paint Worklet (spec)
I am starting with this as it is introduces the fewest new concepts. From the spec draft itself:
The paint stage of CSS is responsible for painting the background, content and highlight of an element based on that element’s geometry (as generated by the layout stage) and computed style.
This allows you not only to define how an element should draw itself (think of
the synergy with Web Components!) but also alter the visuals of existing
elements. No need for hacky things like DOM elements to create a ripple effect
on buttons. This would allow a significant reduction in DOM node count for
common visuals. Another big advantage of running your code at paint time of an
element compared to using a regular <canvas> is that you will know the size of the
element you are supposed to paint and that you will be aware of fragments and
handle them appropriately.
Wait, what are fragments?
Fragments
I think of elements in the DOM tree as boxes that are laid out by the CSS engine
to make up my website. It turns out, however, that this mental model becomes
flawed once inline elements come into play. A <span> may need to be wrapped;
so while still technically being a single DOM node, it has been fragmented
into 2, well, fragments. The spec calls the bounding box
of these 2 fragments a fragmentainer. I am not even kidding.
Back to the Paint Worklet: Effectively, your code will get called for each
fragment and will be given access to a stripped down <canvas>-like API as well
as the styles applied to the element, which allows you to draw (but not visually
inspect) the fragment. You can even request an “overflow” margin to allow you to
draw effects around the element’s boundaries, just like box-shadow.
class {
static get inputProperties() {
return ['border-color', 'border-size'];
}
paint(ctx, geom, inputProperties) {
var offset = inputProperties['border-size']
var colors = inputProperties['border-color'];
self.drawFadingEdge(
ctx,
0-offset[0], 0-offset[0],
geom.width+offset[0], 0-offset[0],
color[0]);
self.drawFadingEdge(
ctx,
geom.width+offset[1], 0-offset[1],
geom.width+offset[1], geom.height+offset[1],
color[1]);
self.drawFadingEdge(
ctx, 0-offset[2],
geom.height+offset[2], geom.width+offset[2],
geom.height+offset[2],
color[2]);
self.drawFadingEdge(
ctx,
0-offset[3], 0-offset[3],
0-offset[3], geom.height+offset[3],
color[3]);
}
drawFadingEdge(ctx, x0, y0, x1, y1, color) {
var gradient =
ctx.createLinearGradient(x0, y0, x1, y1);
gradient.addColorStop(0, color);
var colorCopy = new ColorValue(color);
colorCopy.opacity = 0;
gradient.addColorStop(0.5, colorCopy);
gradient.addColorStop(1, color);
}
overflow(inputProperties) {
// Taking a wild guess here. The return type
// of overflow() is currently specified
// as `void`, lol.
return {
top: inputProperties['border-size'][0],
right: inputProperties['border-size'][1],
bottom: inputProperties['border-size'][2],
left: inputProperties['border-size'][3],
};
}
};Compositor Worklet
At the time of writing, the compositor worklet doesn’t even have a proper draft and yet it’s the one that gets me excited the most. As you might know, some operations are outsourced to the graphics card of your computer by the CSS engine, although that is dependent on both your grapics card and your device in general. A browser usually takes the DOM tree and, based on specific criteria, decides to give some branches and subtrees their own layer. These subtrees paint themselves onto it (maybe using a paint worklet in the future). As a final step, all these individual, now painted, layers are stacked and positioned on top of each other, respecting z-indices, 3D transforms and such, to yield the final image that is visible on your screen. This process is called “compositing” and is executed by the “compositor”. The advantage of this process is that you don’t have to make all the elements repaint themselves when you scrolled a tiny bit. Instead, you can reuse the layers from the previous frame and just re-run the compositor with the changed scroll position. This makes things fast. This makes us reach 60fps. This makes Paul Lewis happy.
As the name suggests, the compositor worklet lets you hook into the compositor
and influence the way an element’s layer, which has already been painted, is
positioned and layered on top of the other layers. To get a little more
specific: You can tell the browser that you want to hook into the compositing
process for a certain DOM node and can request access to certain attributes like
scroll position, transform or opacity. This will force this element on its own
layer and on each frame your code gets called. You can move your layer around
by manipulating the layers transform and change its attributes (like opacity)
allowing you to do fancy-schmancy things at a whopping 60 fps. Here’s a full
implementation for parallax scrolling using the compositor worklet.
// main.js
window.compositorWorklet.import('worklet.js')
.then(function() {
var animator = new CompositorAnimator('parallax');
animator.postMessage([
new CompositorProxy($('.scroller'), ['scrollTop']),
new CompositorProxy($('.parallax'), ['transform']),
]);
});// worklet.js
registerCompositorAnimator('parallax', class {
tick(timestamp) {
var t = self.parallax.transform;
t.m42 = -0.1 * self.scroller.scrollTop;
self.parallax.transform = t;
}
onmessage(e) {
self.scroller = e.data[0];
self.parallax = e.data[1];
};
});My colleague Robert Flack has written a polyfill for the compositor worklet so you can give it a try already – obviously with a much higher performance impact.
Layout Worklet (spec)
Again, a specification that is practically empty, but the concept is intriguing:
Write your own layout! The layout worklet is supposed to enable you to do
display: layout('myLayout') and run your JavaScript to arrange a node’s
children in the node’s box . Of course, running a full JavaScript implementation
of CSS’s flex-box layout will be slower than running an equivalent native
implementation – but it’s easy to imagine a scenario where cutting corners can
yield a performance gain. Imagine a website consisting of nothing but tiles á la
Windows 10 or a Masonry-style layout. Absolute/fixed positioning is not used,
neither is z-index nor do elements ever overlap or have any kind of border or
overflow. Being able to skip all these checks on re-layout could yield a
performance gain.
registerLayout('random-layout', class {
static get inputProperties() {
return [];
}
static get childrenInputProperties() {
return [];
}
layout(children, constraintSpace, styleMap) {
Const width = constraintSpace.width;
Const height =constraintSpace.height;
for (let child of children) {
const x = Math.random()*width;
const y = Math.random()*height;
const constraintSubSpace = new ConstraintSpace();
constraintSubSpace.width = width-x;
constraintSubSpace.height = height-y;
const childFragment = child.doLayout(constraintSubSpace);
childFragment.x = x;
childFragment.y = y;
}
return {
minContent: 0,
maxContent: 0,
width: width,
height: height,
fragments: [],
unPositionedChildren: [],
breakToken: null
};
}
});Typed CSSOM (spec)
Typed CSSOM (CSS Object Model (Cascading Style Sheets Object Model)) addresses a problem we probably all have encountered and just learned to just put up with. Let me illustrate with a line of JavaScript:
$('#someDiv').style.height = getRandomInt() + 'px';We are doing math, converting a number to a string to append a unit just to have the browser parse that string and convert it back to a number for the CSS engine to use. This gets even uglier when you manipulate transforms with JavaScript. No more! CSS is about to get some typing! This draft is one of the more mature ones and a polyfill is actually already being worked on (Disclaimer: Using the polyfill will obviously add even more computational overhead. The point is to show how convenient the API is).
Instead of strings you will be working on an element’s StylePropertyMap, where
each CSS attribute has it’s own key and corresponding value type. Attributes
like width have LengthValue as their value type. A LengthValue is a
dictionary of all CSS units like em, rem, px, percent, etc. Setting
height: calc(5px + 5%) would yield a LengthValue{px: 5, percent: 5}. Some
properties like box-sizing just accept certain keywords and therefore have a
KeywordValue. The validity of those attributes could now be checked at
runtime.
<div style="width: 200px;" id="div1"></div>
<div style="width: 300px;" id="div2"></div>
<div id="div3"></div>
<div style="margin-left: calc(5em + 50%);" id="div4"></div>
var w1 = $('#div1').styleMap.get('width');
var w2 = $('#div2').styleMap.get('width');
$('#div3').styleMap.set('background-size',
[new SimpleLength(200, 'px'), w1.add(w2)])
$('#div4')).styleMap.get('margin-left')
// => {em: 5, percent: 50}Properties and Values (spec)
Do you know CSS Custom Properties (or their unofficial alias “CSS Variables”)? This is them but with types! So far, variables could only have string values and used a simple search-and-replace approach. This draft would allow you to not only specify a type for your variables, but also define a default value and influence the inheritance behavior using a JavaScript API. Technically, this would also allow custom properties to get animated with standard CSS transitions and animations, which is being considered.
["--scale-x", "--scale-y"].forEach(function(name) {
document.registerProperty({
name: name,
syntax: "<number>",
inherits: false,
initialValue: "1"
});
});Font Metrics
Font metrics is exactly what it sounds like. What is the bounding box (or the bounding boxes when we are wrapping) when I render string X with font Y at size Z? What if I go all crazy unicode on you like using ruby annotations? This has been requested a lot in the past and Houdini should finally make these wishes come true.
But wait, there’s more!
There’s even more specs in Houdini’s list of drafts, but the future of those is rather uncertain and they are not much more than a placeholder for an idea at this point. Examples include custom overflow behaviors, CSS syntax extension API, extension of native scroll behavior and similar ambitious things that allow us new things on the web platform that weren’t possible before.
Gimme!
As of now, nothing of the Houdini specs is in Chrome. However, some of them may be available behind a “OMG this is totally not for production” flag soon(tm) in Canary.
For what it’s worth, I have open-sourced the code for the demo (live demo using polyfill) videos I made so you can get a feeling on what working with worklets feels like.
If you want to get involved, there’s always the Houdini mailing list.