#489: review HTML event loop and how things fit into it

Visit on Github.

Opened Mar 23, 2020

Hello TAG!

This is a continuation of the discussion in #197 because the things that I've been keeping that open for aren't really specific to IntersectionObserver anymore.

However, I think we do need to further review the HTML event loop, make sure it's specified clearly enough for new things to slot into it in an interoperable way, etc.

There's a bunch of prior discussion in the above issue and also in a bunch of other issues linked from it.

Discussions

Comment by @dbaron Apr 6, 2020 (See Github)

Note that related issues are whatwg/html#3246 and maybe w3c/IntersectionObserver#263.

Discussed May 11, 2020 (See Github)

Tess: David filed this as a result of other design reviews... had implications for the event loop and how things hook into it. Intent was to take a closer look at what's in the HTML spec, figure out if it can be hooked into by other specifications. We haven't done that... think it's a good idea to use some of the f2f to do this, walk through the existing spec. I moved the milestones onto the f2f. Kind of deep dive that f2f time is better for.

David: Sounds good.

Comment by @hober May 11, 2020 (See Github)

I think we should try to set aside some F2F time for this one.

Comment by @hober May 26, 2020 (See Github)

@dbaron and I looked at this in our May 2020 F2F. We're going to file an issue on CSS to define when batching and flushing happens, so that HTML can hook into those definitions properly. This will help avoid ambiguity like the one @dbaron and @rniwa encountered in this area (where @dbaron thought the text was talking about default style layout flush timing, and @rniwa thought it was talking about paint timing).

Discussed Dec 13, 2021 (See Github)

...also bumped.

Discussed Jul 1, 2022 (See Github)

Rossen & Tess came up with a possible compromise and floated it to the CSS WG in their issue. Rossen will try to get the WG to take this up next week in New York.

Comment by @atanassov Jul 27, 2022 (See Github)

@hober and I looked at this during our London F2F today. The core problem of this HTML event loop issue sits with the CSSWG and pending further discussions and definition (see https://github.com/w3c/csswg-drafts/issues/5115). Until there is progress made, there is not much we can do at the TAG.

Discussed Aug 29, 2022 (See Github)

Rossen: we had this in the agenda for the CSS f2f ... we had a conversation and overall agreement in wg that this is important and we should specify the types of behaviours that are causing flushes in the subsystem in style layout and paint... and what are the patterns to be used to batch as many capabilities as possible. On the back of this we tasked ... and Dbaron... to think about it. [could take a while]. This issue can't make fwd progress before that work comes back. We could keep this open or close it in similar state.

Dan: feel like we should close it.

Tess: Happy to close it. When CSS group comes back we could get an update. Don't feel we need to keep tracking issue open.

Peter: yes ok.

Rossen: can close it

Discussed Sep 26, 2022 (See Github)

Tess: Rossen brought this to the CSSWG, so maybe we're done here?

... last time we looked at it, we came to the conclusion the most important thing to do was to follow up with CSS wg... Rossen brought to CSS WG. They're discussing. Not the TAG's role to do the spec work.

Peter: Shall we close it?

Rossen: I'm fine with closing it.

Peter: how does it tie into getting Houdini task force up and running?

Tess: last week we talked about batching & flushing.. a notion that this was something Houdini could take up. Low level parts of CSS that historically not descibed in documents... actually in Houdini's wheelhouse?

Rossen: on one side I agree.. on the flip side, internal details of css ... if we don't continue to force those discussions with CSS WG.. might not be more expedient...

... some commitments by CSS WG members made.

Tess: maybe we can just wrap up.

agreed to close

Peter: several new APIs where people are synchronously flushing layout / style - we kind of want to extend into a generic design principle.

Rossen: do we have a design principle that says "avoid sync api"?

Peter: we have an open issue - avoid sync apis that cause style / layout flushing. https://github.com/w3ctag/design-principles/issues/388

Rossen: I think we can write this - we can give some examples.

Peter: we don't have a good defintion of what it means to flush layout or style. I agree we can have the principle w/o a def.

Rossen: as a path forward

issue added to next week

Comment by @hober Sep 26, 2022 (See Github)

The CSSWG (Emilio and @dbaron, specifically) agreed to take up the batching & flushing issue at a recent CSSWG F2F, so we're closing this at our end. We look forward to seeing where they get with this.