Rossen leaving note abour explainer.

Peter left comment about not being async.

Dan: back with us

Peter: inclined to keep pushing back.. other things being broken is not an excuse to introduce one more broken thing. I'd like to hear from Rossen and Lea.

[next week]

Dan: Another async / sync thing.

Peter: we want Lea's input.

punt to plenary

Peter: sync vs async... Last we talked we wanted to get Rossen's input. I feel this is a design mistake across the platform....

Tess: Intersection observer v2 ... what does this do that intersection observer doesn't? It adds convenience.

Peter: this doesn't take the viewport into consideration

Tess: the default ... they can specify the container...

Peter: their argument against makint it async is that it's inconvenient - and it's only inconvenient because developers are used to sync - which isn't good for performance.

Tess: yes.

Dan: Do we need a finding?

Peter: maybe - it's unfair to push back on individual things... But we also have the principle of "just because something's bad don't keep making things bad in the same manner"... May be worth making a concerted effort to find these tings and raise issues in working groups.

Tess: dbaron and I had a discussion about what it means to flush layout... some issues... in medium term we will not have a definition [in CSS wg] of flushing that is something we can cite. If we want such a list to exist we'll have to do it ourselves.

Tess: Hard to say "don't do this" without a definiton of "this". We have to say what we mean by "flush layout."

Peter: we could create a task force. It's within our scope to make a list of APIs...

Tess: we already have a task force...

Dan: should we push this to Houdini?

Peter: Houdini hasn't been active... One of the chairs needs to do this.

agreed to assign this to Rossen

Lea left comment asking for clarification.

Dan: we've had some comments..

Lea: I'm not following the argument

Peter: the aspect that makes sensne to me is mixing sync and async functionality, some will affect layout and some won't

Lea: if the API is async it will give them stale information?

Peter: I'd think it would give you more up to date inforation

Lea: exactly

Peter: to me it's an argument that all these other APIs should be async

Lea: Perhaps there's a misunderstanding about what an async api would do if they think it will result in stale information

Peter: looks like argument is about raf(?) callbacks so .. you get the result but in the process raf is called and somebody has changed the DOM. I don't know if that would have been called before or after the async stuff would have resolved

Lea: right. Who can we ask? Seems like a low level question. Should we ask an implementer if this is accurate?

Peter: isn't Vlad an implementer who would know? Trying to work out if it really matters.. if you have raf callbacks and you're manipulating the dom.. it just changes the order of execution I guess, the information wouldn't be stale but it will c hange things anyway so what does it matter

Lea: appplies to any async api about layout

Peter: not sure the argument is complelling

Lea: so it's correct?

[scribe missed a bit]

Dan: let's ask Tab

Peter: I don't recall this being discussed recently in the CSS WG

Lea: it was discussed a lot a long time ago, but not so much sync vs async, but more about the name and what visible actually means etc.

Dan: who is vmpstr ?

Rossen: Vlad from Google.

Peter: it's part of a bigger problem that we have a number of sync methods that should have ben async from the get go and we're just adding more. We need a comprehensive look at all of these and move towards making them all async rather than arguing each one

Lea: we do have a design principle for that

Peter: the problem is.. I don't think we're going to get that end result of where's the effort to fix this problem as a whole as opposed to fighting it for each individual new feature. To me that feels like a Houdini problem. What's happening with that?

Rossen: every time I ask folks, they say "we should!" And that's where it ends.

[discussion about how CSS WG works]

Peter: propose opening Houdini issue...

Rossen: There's issue 5115 in css working group... if we have more specific guidance from CSS on this issue then we can apply it here [in #734]. This is how you avoid breaking the loop...

Peter: My concern: giving more APIs that are async ... it's related... we need a definition of what the loop is and what it does. Follow-on task : proposing async replacements...

Rossen: we can open a separate Houdini issue and have discussion there...

Rossen: Tess & I concluded (in review of event loop) that if we have this [5115] issue done and something we can point to then everything else becomes much easier.

Peter: I will file an issue in Houdini and reference these other issues and we go from there.

Peter: we opened up the issue in Houdini about sync/async as a bigger deal...

Dan: shall we put this on hold?

Rossen: it's not necessarily CSS only related.. We could spend some time on CSS call this week, some of the right people could be there.

bump to plenary for maybe an update from CSS

Peter: one of thos sync / async / flush style... I don't think we can advance until Houdini work has been done.

Dan: It is already shopped.

Peter: CSS wg has approved it...

Peter: it's on Element...

Dan: Other implementations?

Peter: from caniuse blink and firefox - so at least 2 implementers...

Rossen: so fairly down the path. What can we add?

Peter: I think it's fodder for sync vs/async discussion...

Rossen: I think we should close this one and have the discussion in the principles issues...

Peter: That's reasonable... I'm fine with closing this one... Not sure if we should do the same with the others yet.

Peter: fine closing it with concerns.

Dan: closed with "satisfied with concerns" label.

Peter: one of the synchronous APIs we think should be async... Some work to make older APIs async?

Tess: all kinds of issues - opacitiy 5%... etc.. API will lie and say it's visible when humans can't see it. If it's being used for ad impression measurement use case then it's not resiliant to fraud.

Peter: the explainer talks about visibility, opacity, display:none,.. talks about closed shadow tree... talks about 'would it be visible in the viewport'... links to draft spec..

Dan: asks for an update