Last week I was in Sydney for the first face to face meeting of “CSS Houdini”, a new joint task force of W3C’s CSS Working Group and Technical Architecture Group.

The goal is to “explain the magic” of CSS, make it extensible by providing low-level primitives that can be built upon to add new higher-level features to the platform without baking them into browsers.

Participants were from Microsoft, Google, Mozilla, HP, W3C, Disruptive Innovations, Apple, Vivliostyle, Adobe, and jQuery Foundation.

I have heard concerns that Google or Apple would just expose whatever Blink/WebKit’s internals currently are, and the rest of us implementers would be stuck with that. Since this work is happening at W3C and participants include people working on competing engines, I am confident this won’t happen. I will also be watching for design decisions that could be incompatible with Servo’s goals (e.g. parallel layout, layout concurrent with script, etc.)

About the task force:

Mailing list:
IRC: #houdini @
Draft specifications:
Source repository:
Read/write mirror repository (pull requests work):

Formatted minutes of these discussions should be published soon. In the meantime, the raw IRC logs are at:

The group agreed on its own scope, and on starting new 8 specifications. I described them below based on my the minutes and my own recollection of the discussions. If you want to discussed the proposals themselves (as opposed to their implications for Servo), please do so on the mailing list. (Subscription info is at the URL above.)

* Fragment Tree

Expose read-only information to script about the fragment tree, which is roughly what implementations call the render tree, frame tree, or flow tree. This includes "anonymous" fragments, that are not generated directly by any DOM element. This was previously discussed as a "Box Tree", but was renamed since boxes (as defined in CSS specs) don’t have geometry, only fragments (again per spec, after fragmentation across lines, columns, regions or pages) do.

* CSS Parser API

Expose various pieces of the CSS parser: selectors, rules, complete stylesheets, colors, gradients, unknown properties, etc. Web authors are often doing this ad-hoc with regular expressions, which is painful and hard to get right. The shape and API of returned objects (representing tokens or an AST or higher-level values) is yet to be determined.

* CSS Properties and Values Extensions

Currently, CSS implementations throw away (per spec) rules or declarations they don’t understand. The error recovery and fallback allow for some forward-compatibility, but this is somewhat limited. We now also have CSS Custom Properties, but they’re namespaced with the -- prefix. This proposes adding APIs enabling script to register new at-rules and properties with a details about their behavior and callbacks for parsing, as well as new values for existing "types" (e.g color, length, image, …), thus enabling polyfills.

* Font Metrics Extensions

Some desired features like drop caps a.k.a. initial letters require various measurements from fonts such as position of the baseline, height of ascenders and descenders, etc. This proposes APIs to determine which font is actually used for a given piece of text in the document (since the `font-family` property accepts a list of family names) and query such measurements.

* Custom Paint

This proposes adding callbacks into script during painting, to enable various graphical effects. One example given was an animated procedural background image of ripples, as if on a fluid surface, that propagate from a disturbance point and bounce against the borders of the element.

* CSS Custom Layout

This propose adding the ability to define new layout modes (like Flexbox is a layout mode) in script, with callbacks for the various phases of layout. These modes would probably be opted into through new values of the 'display' property.

* CSS Scroll Extensions

This proposes adding hooks to control scrolling (e.g. for snap points), and what scrolling should block on (e.g. slow scroll event handlers).

* CSS Async Style

As far as I understand, this proposes adding control on what phases of rendering of what parts of the document can be deferred or (de)prioritized.

Simon Sapin
dev-servo mailing list

Reply via email to