Review CSS Houdini

[annevk]

I'd like folks familiar with Servo's architecture to review the CSS Houdini work (exposing more of CSS to JavaScript). To ensure the architecture put forward by those drafts doesn't invalidate (planned) architecture in Servo and shifts envisioned by Servo (such as from immediate mode to retained mode driving of the GPU) can be accommodated.

Drafts of interest:

• CSS Painting API
• CSS Typed OM
• CSS Properties and Values API
• CSS Layout API

Issues can be filed at https://github.com/w3c/css-houdini-drafts/issues/new.

[Manishearth]

cc @SimonSapin who IIRC has been following this closely

[SimonSapin]

CC w3c/css-houdini-drafts#308

Regarding GPU driving, CSS Painting API currently relies on 2D canvas which is already part of the platform.

[notriddle]

Regarding layout:

The CSS Layout API uses a single-pass layout scheme centered around a doLayout() function. This function yields promises, so it is possible for a JavaScript-based layout to call doLayout() on all its children, then yield them all at once. If the browser runs the actual work in separate threads, this will allow parallel layout.

The Houdini team has created a parallel layout algorithm that can perform a naive block layout that ignores floats. I think Servo basically dismissed this approach after the first meeting.

The problem with floats is that you can't know if (or to what extent) float F will impact box A until you compute the height of the boxes between box A and float F. Servo's able to eek some parallelism out of this situation because it computes the widths of all boxes before it even gets started on the heights, and the only case where floats can affect the width of a box is if that box is a block formatting context (we guess the width of such boxes and double-layout it if we get it wrong; horrible hack, but we guess right most of the time). We can't avoid sequentially computing the heights of non-formatting-context block children that may be impacted by floats, and we do it at the same time as line breaking. Did I mention it's a good thing most floats are eventually cleared?

Tables show the advantages of Servo's approach more clearly. If you start with the widths and then move onto the heights, it's actually easier than a sequential algorithm. You compute the width of all the columns, then the height of all the cells, then stretch out any cells that aren't the tallest in their row. Calling it in order requires you to backtrack. I think WebKit and Gecko also uses multiple-pass algorithms in this case.

The specification allows a user-agent to call doLayout() on a child multiple times to retrieve different information, which I think was intended to help this use case. It also requests that worklets be idempotent. Besides the fact that calling a function multiple times to get different pieces of information is inefficient, idempotency is necessary, but not sufficient, for this kind of scheme.

Consider this layout() function, which doesn't lay out its children, but illustrates the point on itself:

registerLayout('blatantly-illogical-box', class {
    *layout(space, children, styleMap, breakToken) {
        return {
            fragments: fragments,
            inlineSize: space.blockSize || 2,
            blockSize: space.inlineSize || 2,
            /* etc. */
        };
    }
});

When performing sequential layout, an engine would provide both inline and block size as part of the initial call. In a Servo-like parallel layout, however, its initial call would only provide the available inline size, so this function would return 2 for its initial inline size. Then, when it goes to get the block size, the inline size changes.

I feel safe in assuming this would also give different behaviors between WebKit and Gecko if it was thrown in a table or something. If we want this to be interoperable, we need far more than idempotent functions. We need to define what constitutes logical behavior for a layout node.

[metajack]

cc @metajack

[asajeffrey]

I'm taking a look at the Worklets spec (https://drafts.css-houdini.org/worklets/) which is used in paint and layout. This also came up in the context of our embedding API, as a standards-aligned way to have script run tightly synchronized with layout and rendering. cc @tschneidereit @metajack.

[nox]

Is this issue worth keeping open? Should we move the "review" part to the mailing-list maybe? AFAIK all but layout worklets have a implementation now (though 'Properties & Values' didn't land yet).

[jdm]

Nobody has looked at the typed OM afaik.

[asajeffrey]

I think we may as well keep this as the meta-bug for Houdini, perhaps editing the title?

I think @jyc was looking at typed OM? There's #18167, which is still open.

[jyc]

Hi @asajeffrey! Sorry for the delay, I did not expect it to be so long. Interviewing for jobs and doing coding tests is taking up all of my time... I don’t think I’d be able to get to implementing Typed OM soon. I’d like to finish up addressing review comments for Properties & Values, but I won’t have the contiguous time for a couple weeks for the refactors that were requested.

[asajeffrey]

@jyc np, thanks for keeping us in the loop. Good luck with the job hunt!