Rossen: this moved to WICG, the explainer link won't get you there

Tess: can you fix the link in the issue?

David: most recent comment says it's in the master explainer now

[aside conversation about change policy related to documents under review. rossen explained how it works for another api review board he participates in. we don't currently have such a policy. Hard to have document stability when reviewing living standards.]

Tess: L.I.S.E.S. is a very dense name. what does it even mean? ELI5

David: does "surfacing" here mean "we are surfacing this data with an API"

Rossen: yes.

... the idea is you compute a layout stability score, which is an approximation of how much layout has changed between rAF frames. 0 means no change. anything more than zero means your layout is not stable.

... this score is computed based on shifts that are not caused by transforms or scrolling. IOW if you're animating with transforms, your layout is actually stable. this is to catch dom nodes being inserted / removed, etc.

... this feature is intending to compute the cost of reflow at the document level by aggregating these per-frame scores.

... they have a couple of different multipliers, an impact fraction and a distance fraction. the impact fraction is a bit confusing. it computes a fraction based on the elements box in comparison to the overall animation frame. i don't know how and why that matters that much. distance is straightforward.

David: this came in post-wellington and assigned to today. i haven't looked at it. i feel some deja vu looking at this. there have been multiple attempts to solve this problem before. we've reviewed 2 or 3 of them.

Tess: why will this approach succeed when the previous ones didn't?

David: one thing I'm not understanding: how does what we're being asked to review here relate to the overall API we reviewed in w3ctag/design-reviews#393. i think what we're reviewing now is the "source attribution" section.

... i should read the source attribution section more closely.

... this is about saying in these layout shift reports it will put up to 5 elements and list them so the website can figure out what the problem is when it sees high layout shift numbers.

Tess: should we push this out?

David: i just read it. it has the feel of a lot of the web performance work. sites are having these problems, so we fish around for metrics to expose to help people debug their problems. the way to find that out is to get it out there and see if it's useful for people.

... one question: do these accumulate in a way that will keep orphaned nodes alive? i should add a comment with some questions.

Tess: okay, let's leave those questions & mark as 'pending external feedback'.

Rossen: in the privacy section, it says this exposes resource timing, and that means fingerprinting. it's limited to the current browsing context. re: resource timing and fingerprinting, i don't see why this doesn't apply to this api too.

Tess: sounds like a good question to ask them

[push out one week

Rossen: need to spend some additional time on this one. The overall feedback was "sounds like a useful thing"... "why didn't the previous approaches work?"

...addresses layout jank across

[bump 2 weeks