Define concepts of batching and flushing of style and layout information

[dbaron]

It's not entirely clear what spec this should go in, but I think it is within the CSS Working Group's space.

In whatwg/html#3246 there's a discussion about better specifying the concepts of batching and flushing of style and layout information. I believe it's desirable to specify this in a good bit more detail than it's specified now, because it has significant effects on things like:

• performance characteristics of APIs
• the order in which various events or notifications fire (which can affect interoperability)

That doesn't mean it should necessarily be specified in all detail. It might be desirable to leave room for optimizations that don't exist today, such as updating style or layout for part of a document tree rather than all of it -- though those optimizations might also be difficult to do because of compatibility issues (which would suggest that the details they depend on should be specified).

So, in particular, I think some document in the CSS working group needs to define the idea that certain sets of changes can be buffered up rather than being executed immediately, and then it needs to export definitions that other specs can link to for something like flush style and flush layout. This can then allow other APIs to say when they do these things, and also allow various other things that send notifications (like resize events, IntersectionObserver, or ResizeObserver) to specify more clearly whether the notifications are triggered by any layout, or only by the primary layout within the update the rendering steps.

This would also help make progress on the broader goal of helping other specifications figure out how to integrate with batching/flushing and with the update the rendering steps.

(Filed during a breakout at the TAG's virtual face-to-face where @hober and I are discussing w3ctag/design-reviews#489.)

[domenic]

So, in particular, I think some document in the CSS working group needs to define the idea that certain sets of changes can be buffered up rather than being executed immediately, and then it needs to export definitions that other specs can link to for something like flush style and flush layout. This can then allow other APIs to say when they do these things, and also allow various other things that send notifications (like resize events, IntersectionObserver, or ResizeObserver) to specify more clearly whether the notifications are triggered by any layout, or only by the primary layout within the update the rendering steps.

My worry about an architecture like this, compared to the current one, is that it makes it easy for specs to forget to include the "flush style" and "flush layout" steps. (Whereas now they are implicit.) On the other hand, I am neither a spec or implementation domain expert on style and layout.

Do you think everyone writing specs that would need to include these steps will have the necessary domain knowledge to know that they should insert these calls?

[dbaron]

I think you're right that they wouldn't. We'd need to figure out a reasonable way to do this safely in a way that still makes things better defined.

[hober]

Who's eyes should we try to get on this? @emilio's? @tabatkins?

[tabatkins]

Probably not me? I am specifically one of the people without the necessary domain knowledge that Domenic is mentioning. I know that some operations flush layout/style, but don't know the full list, anything about the timing, or any more advanced details about partial vs full layouts that dbaron is mentioning.

And the fact that I don't know any of this, despite being a long-time and prolific editor with experience cutting across the entirety of CSS, strongly supports Domenic's point that defining this in more detail with the expectation that the detail will be applied correctly where it is needed is probably not realistic.

[hober]

@atanassov & I took a look at this during the TAG's F2F in London today.

I think @dbaron makes a good case that this stuff isn't currently defined with enough rigor (see this issue itself, this comment, etc.), but also @domenic's right that pushing the maintenance burden onto ALL THE SPEC EDITORS, most of whom don't have the relevant expertise, isn't a good way to solve the problem.

A (handwavy, super-high-level) possible compromise would be to write some spec text describing how this all works, but only provide one hook for other spes, for the less common case (is that the "force flushing" case?). There's a one-time operation that many folk familiar with implementations could do, namely, make a list of the things that fall into the exceptional case, and then the WG could update those specs appropriately. Going forward, people adding new features need only ask themselves, is this one of the exceptional cases, and if so, use the hook. Most of the time, they won't have to.

Maybe this is something folks can consider during next week's CSS F2F.