#393: Layout Instability Metric

Visit on Github.

Opened Jul 8, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details:

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

  • Links to major pieces of multi-stakeholder review or discussion of this specification:

https://discourse.wicg.io/t/proposal-layout-stability-metric/3187

  • Links to major unresolved issues or opposition with this specification:

https://github.com/WICG/layout-instability/issues

You should also know that...

  • some tests are not yet in WPT
  • some properties (hadRecentInput, lastInputTime) are not yet described in the spec

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our GitHub repo for each point of feedback
  • open a single issue in our GitHub repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

Discussions

2019-07-10

Minutes

Alice: it's new. they are wondering if they can get an expedited review. I can explain.

Alice: they are adding an extra interface into the perf API to get metrics on performance to send back to the server to test whether your changes have impacted performance. new performance entry type. it is aimed at measuring jank. They have a jank score.

Lukasz: measuring how far the current layout is compared to the layout that is supposed to visible...?

Alice: it's more about - what does the user perceive about how stable the layout is. E.g. ads that load that cause the page to jump when you load it.

Lukasz: sounds engine dependent and user dependent ? Depend on engine, network, related to the user's... this info will only be provided to the web site?

Alice: as opposed to what?

Lukasz: might be misued by web sites ... like use an adversarial layout... not sure if it's possible to devise a blueprint of an adversarial display that ... may be overthinking.

Sangwhan: looking at the algo it looks like if there is a font that loads too late this will have a really large value.

Alice: excellent question ... to leave on the review.

David: I am generally worried both about whether we will be able to make it interoperable and also whether it's the thing that will be the best to optimise for or whether it will lead people to optimise for the wrong thing.

Alice: is optimising for the wrong thing still an imporovement?

David: often but not always.

Peter: question on how does the performance observer API work... does it fire any time layout changes? Root question is : are we expediting this, who is doing it and when?

David: i am happy to be involved.

Alice: Lukasz do you want to be on this?

Lukasz: sure at least about the issues I mentioned. yes. put me down.

Alice: i will assign myself.

Peter: milestone?

Peter: noting 2 things on the agenda for next weeek

David: let's try

[set for next week

2019-07-17

Minutes

Lukasz: The ? part of the reply I'm not commenting on. There are more metrics out there. The last part says we have nothing to worry about because there are other ways to do that... do what? Can I ask what it is that might be an issue? I'm more and more skeptical about this point of view -- just because something is possible with something, doesn't mean it's ok to add other things that do the same. Or at least have it catalogued.

Dan: Sounds good to me. Often claims of no privacy concern say "the information can already be found with this other API". I'm skeptical; is that a reason to dismiss that the new API can be used to get private data. I think it's worth asking that question.

Lukasz: So I'll reply.

Dan: Other thoughts?

David: I'd like to look at it more. For the interaction with layout perspective.

2019-07-24

Minutes

Alice: no responses since last week. Numbers don't seem to be very percise... variation between browsers. [some discussions of comments left on issue]. How do yoi measure this in a way that makes sense...

Peter: Florian raised a bunch of concerns - message sent to blinkdev... july 20th.

[...reading...]

Alice: some of his comments are spec issues... [editorial] ... don't understand the fragmention comment... he makes the point that there are spec issues that may cause trouble for interop.

Dan: can we ask them to come back to us when they revise?

Alice: we are waiting on responses to issues we raised - we could just set it to progress: pending external feedback ?

[discussion on whether to bump]

Alice: how do we recapture things once they have feedback...

Dan: meta issue - let's discuss - maybe we can use a bot

Peter: bot that looks for issues on pending feedback and looks for new comments from non tag members and flags that..

2019-08-21

Minutes

Alice: Breakout in which we will file issues - regular breakout time, 5pm Thursday US Pacific time

2019-09-04

Minutes

Alice: I filed a couple of issues.

David: Alice & I filed some issues. A response came in 14 hours ago.

Alice: In terms of granularity - made a good poont that the cumulative score is what is meaningful. Exposing the raw score with developer guidance is what needs to happen.

David: their responss to comments seem reasonable.

David: should this be in webperf?

Dan: can we close it?

David: I'm OK closing it. Just typing up a comment that it would be useful to have guidance in the spec? We can lgtm and close it