Layout Instability Shifted Element Surfacing

[skobes-chromium]

Hello TAG!

I'm requesting a TAG review of Layout Instability Shifted Element Surfacing.

Today it is difficult for web developers to understand the cause of a high CLS score using the Layout Instability API, because nothing in the score or the PerformanceEntry connects back to the specific DOM elements that were affected by the layout shift.

CLS Shifted Element Surfacing (SES) is an effort to surface a subset of the shifted DOM elements in the LayoutShift interface. This will improve the "actionability" of CLS for developers.

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/layout-instability/blob/master/README.md
• Specification URL: https://github.com/WICG/layout-instability/pull/32/files (will update when landed)
• Tests: coming soon
• Security and Privacy self-review²: this extension does not alter the security and privacy considerations of the overall Layout Instability API which were submitted with Layout Instability Metric #393
• GitHub repo (if you prefer feedback filed there): https://github.com/WICG/layout-instability
• Primary contacts (and their relationship to the specification): skobes
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification: Expose what caused the layout instability. WICG/layout-instability#11
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Expose what caused the layout instability. WICG/layout-instability#11

Further details:

• I have reviewed the TAG's API Design Principles
• Relevant time constraints or deadlines: n/a
• The group where the work on this specification is currently being done: WICG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): W3C
• Major unresolved issues with or opposition to this specification: n/a
• This work is being funded by: Google

You should also know that...

This feature adds a new attribute ("sources") to an interface defined in an existing specification (Layout Instability). The PR to amend the spec with this feature is not yet landed but we are proactively initiating TAG review to optimize the time available to review. There is some discussion on the PR review thread which may alter some aspects of the API.

We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[torgo]

Hi! On "The group where standardization of this work is intended to be done" can you be more specific? Will this be going to the web performance working group?

[torgo]

On the explainer, can you please take a look at our explainer explainer? We'd really like to see more info here – and please remember this explainer is not intended to just be for the purposes of the TAG review. It's about writing some documentation about how the technology works that will keep providing value down the line as the spec matures...

[skobes-chromium]

Thanks for the comments and apologies for the delayed update.

Shifted element surfacing has now been added to the master explainer for the Layout Instability API. The "Source Attribution" section describes the new attribute. I think this makes more sense than having a separate explainer, since this is an extension to an existing API rather than a brand new API.

The updates to the spec have also been committed; the sources attribute and the LayoutShiftAttribution interface are now included in the Layout Instability API specification in WICG.

Standardization of this work is intended to be done in the CSS web performance working group.

[dbaron]

So we looked at this briefly in our Breakout B today.

A few thoughts:

• How long lived are these LayoutShift performance entries going to be? Is there a risk that they'll (via the LayoutShiftAttribution) entrain a bunch of dom nodes that would otherwise be garbage and cause memory leaks? (And would this happen on all pages, or just those that invoke certain things?)

• In general, a lot of this feels like trying things to figure out what metrics are going to be useful for sites to figure out their performance problems. It's... hard for us as the TAG to guess what's going to be useful here, other to say it would be great if the end result is that the successful experiments end up baked into the web platform and the unsuccessful ones don't.

[atanassov]

Another question based on your Privacy Section, can you elaborate why does "statistical fingerprinting" apply to resource loading but not Layout Instability?

[skobes-chromium]

On memory leaks: this actually came up on the PR and we made some changes as a result: LayoutShiftAttribution does not retain a DOM node after it is removed from a document. The getter for the node attribute returns null in this case (via the "get an element" algorithm from the element timing spec). So the attribution acts like a weak pointer, and still provides some information (new and previous visual rects) when node is null.

On privacy: we do not claim that fingerprinting applies to resource loading but not layout instability. On the contrary, the intent is to disclose that layout instability is affected by resource loading, and therefore shares the same theoretical fingerprinting opportunities.

[dbaron]

From #485 (comment):

Standardization of this work is intended to be done in the CSS web performance working group.

Did you mean the CSS Working Group, the Web Performance Working Group, or some combination of them?

[dbaron]

@atanassov and I just took a look at this again in a breakout at our virtual face-to-face. I think we're happy closing this; what we've seen seems reasonable. We encourage you to continue to get feedback from the appropriate working groups (I suspect Web Performance is probably the right venue but that it's useful to get a bit of feedback from CSS), and to get data on whether this is a useful approach for the performance that affects users and for what developers want to measure.

[skobes-chromium]

Thanks - I think I meant the Web Performance working group, which publishes specs for APIs like Performance Timeline, Paint Timing, etc.