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.

[atanassov]

I'm reminded of the early efforts around animations and helping spec authors define how their properties would or wouldn't animate. We made it explicit and mandatory part of the spec template to define the animation expectation, and as a result ensure an overall predictability of CSS animations.

[tabatkins]

I think animation is a vastly easier concept to understand and define. Making it a required part of the propdef template meant spec authors couldn't forget to add it, which is obviously great, but it didn't need to teach spec authors about the concept. A few moments thought usually answers the question of what to put there.

It was also a single obvious location (each and every propdef block), which could be linted like this, versus arbitrary, unpredictable spots in random algorithms, which absolutely cannot be linted.

[css-meeting-bot]

The CSS Working Group just discussed Batching and flushing of style/layout info.

The full IRC log of that discussion

<TabAtkins> Topic: Batching and flushing of style/layout info
<fantasai> s/statuses/ready-to-ship list/
<dbaron> github: https://github.com//issues/5115
<dbaron> github: https://github.com//issues/5115
<TabAtkins> Rossen_: this was brought up as part of a longstanding TAG review of the html event loop
<TabAtkins> Rossen_: as we looked at last week's TAG f2f, Tess and I were looking over all the issues, what was discussed between whatwg and tag and here
<TabAtkins> Rossen_: This was the most relevant issue, defining when styles are batched and flushed
<TabAtkins> Rossen_: wanted to bring it up to the WG to review
<TabAtkins> Rossen_: For us to encourage and define how batching/flushing takes place
<Rossen_> q?
<TabAtkins> Rossen_: I was hoping to hear from tab or dbaron or emilio on this topi
<fantasai> TabAtkins: My conclusion is, as I commented in the thread, knowing exactly how and where styles et batched and flushed is something that I do not know very well
<fantasai> TabAtkins: and I don't anticipate other authors knowing either
<fantasai> TabAtkins: So we should make this implicit, with as minimal manual effort as possible
<fantasai> TabAtkins: Anywhere we leave it up to authors, it will inevitably get messed up
<Rossen_> ack dbaron
<fantasai> dbaron: I think my original suggestion was pretty wrong
<fantasai> dbaron: I think the question is it's not entirely clear to me what the right thin to do about it is
<fantasai> dbaron: I think one possibility is that we might be able to write some wording that says, the following steps happen whenever X happens, unless explicitly specified otherwise
<fantasai> dbaron: the question is whether we can write that clearly enough that it's actually correct
<fantasai> dbaron: because there may be places, there are algorithms like interesctionobserver and resizingobserver
<ChrisLilley> q+
<fantasai> dbaron: that would need to say something explicitly
<fantasai> dbaron: What's not clear to me is whether other algorithms need to say something explicit
<fantasai> dbaron: needs someone to sit down and spend a few days trying to figure it out
<fantasai> dbaron: I've been intending to do since filing the issue
<fantasai> dbaron: Given that, I shouldn't maybe make any promises
<emilio> q+
<fantasai> dbaron: it's quite substantive
<Rossen_> ack ChrisLilley
<fantasai> ChrisLilley: Happens whenever is insufficiently precise
<fantasai> ChrisLilley: it has to happen immediately before or immediately after
<fantasai> dbaron: I meant that
<fantasai> emilio: I wanted to say, this problem has gotten more complicated than it needs to be
<fantasai> emilio: due to some new features
<fantasai> emilio: This containment feature, content-visibility
<fantasai> emilio: Prevents flashing of style and layout in some cases, in some subtrees
<fantasai> emilio: display-locking
<fantasai> emilio: and same for a bunch of other APIs
<fantasai> emilio: getComputedStyle, updating style on the element you're queryign
<fantasai> emilio: can cause potentially visible side-effect, e.g. not updating transitions in other parts of the page
<fantasai> emilio: very trick
<Rossen_> q?
<Rossen_> ack emilio
<fantasai> emilio: defining precisely when an element does style updates, I don't think it's possible
<fantasai> emilio: ...
<fantasai> emilio: It's not a great spot to be in
<dbaron> s/I meant that/I meant before/
<fantasai> Rossen_: Just to drive this forward
<fantasai> Rossen_: One way is for us to undefine this, and precisely channeling a little of what Tab was saying, is to say this is not to be defined
<fantasai> Rossen_: and move on
<fantasai> Rossen_: which would allow at least us in TAG to close the event loop issue
<fantasai> Rossen_: and say we don't have a well-specified event loop
<fantasai> Rossen_: which most of the platform depends on
<fantasai> Rossen_: but you get what you get
<fantasai> Rossen_: that's an unsatisfying place to be in
<fantasai> Rossen_: I think authors, both feature authors and spec authors, would like a bit more specificity or visibility into at least what would cause a forced flush
<fantasai> Rossen_: if we can define some of the really big landmines that ought to be avoided if possible
<fantasai> Rossen_: that would be a good step in the right direction
<fantasai> Rossen_: so at least as ppl add their ??, they might not get a clear picture of batching
<fantasai> Rossen_: but if you get a place when forcing flush
<fantasai> Rossen_: can avoid it
<fantasai> Rossen_: We can't currently do that
<fantasai> Rossen_: ...
<fantasai> Rossen_: If we can't get to that sort of granularity, at that abstract level
<fantasai> Rossen_: that's unsatisfying state to be in
<fantasai> emilio: Might be useful to get all the engines to gether, see what the different optimizations are, and see if we can come up with a way to define a minimum common denominator that we can all agree on
<fantasai> emilio: Then there's also the work of going through all the APIs
<fantasai> emilio: but hopefully getting tricky parts agreed on can help
<fantasai> emilio: I agree that it's really unfortunate if we don't end up having it consistently applying
<fantasai> Rossen_: Emilio, can you organize this?
<fantasai> emilio: I can try. Between me and dbaron maybe we can get it done
<fantasai> Rossen_: OK, so this is a good point to take a break