- From: Lukasz Olejnik <notifications@github.com>
- Date: Mon, 22 Jul 2019 04:37:36 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 22 July 2019 11:38:00 UTC
Thanks for your answers @skobes! > These are good questions to think about. It's already possible for a site to query an element's bounding rect, but it is infeasible to query every element at every point in time. So I would say the metric enables observing layout changes in a way that isn't efficient today. So it seems to me it is in fact introducing something that is not possible today (it might be possible, maybe, with different approach, less efficiently, etc?) after all. Why not document this down? Any view on manually introducing element jitter? > > > I think a rough guideline on scoring might be > 0.0 - 0.1 = low jank > 0.1 - 0.5 = medium jank > 0.5 - 1.0 = high jank > > Scores above 1.0 are possible but the differences become less meaningful. (The highest scores tend to be sessions with auto-repeating layout-inducing animations.) Looks good. Would it be possible to reduce values>1 to 1, and perhaps even keep just 0, 0.2, 0.5, 0.7, 0.9, 1? Alternatively 0.{1,2,3,4,5,6,7,8,9}, 1. > > I expect we'll refine our understanding of this over time based on the data we observe in the wild. How long would this observation phase last? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/393#issuecomment-513755486
Received on Monday, 22 July 2019 11:38:00 UTC