search

WICG / layout-instability

A proposal for a Layout Instability specification
https://wicg.github.io/layout-instability/
Other
159 stars 27 forks source link

explainer should perhaps explain how much the metric is intended to evolve over time and vary between implementations #23

Closed dbaron closed 5 years ago

dbaron commented 5 years ago

I think one of the major questions around the design of this spec is the following: it seems like figuring out what developers should optimize for in terms of stability during load is a question that has active research. At least, I don't think there's an agreed-upon answer for what the perfect thing to measure is.

So for this specification, it feels like there's a tension between (a) specifying something that's precisely interoperable versus (b) specifying something that can be improved on over time (e.g., where browser engines could have different opinions on what type of instability is best/worst for their users, and could improve that metric over time).

I'm curious both where you think the current spec fits along that tradeoff/continuum, and what you think advantages/disadvantages of shifting to a different point along that continuum would be. This seems like something that could perhaps be discussed in the explainer.

Something else that I think either the explainer or the spec should explicitly state: is this spec intending to evolve the definition of the metric over time in response to feedback, or is it intended to become stable at some point?

(I got here from w3ctag/design-reviews#393.)

dbaron commented 5 years ago

And I guess the explainer does say:

The user agent may trade off precision for efficiency in the computation of LS scores. It is intended that the LS score have a correspondence to the perceptual severity of the instability, but not that all user agents produce exactly the same LS scores for a given page.

but it says that after defining quite precisely how the LS score is computed.

That also doesn't say so much how this is intended to evolve over time.

skobes-chromium commented 5 years ago

I think it makes sense for the metric to evolve over time. The spec gives a precise definition of the current state of the metric. We should not consider it "frozen".

But it probably doesn't make sense for browser engines to vary significantly (such that developers must choose between optimizing for one browser's implementation versus another's).

The precision / efficiency tradeoff is something we struggled with in Chrome. Initially we saw a high cost to calculating the impact region, which we mitigated by reducing the resolution at which the region calculations are performed. Later on we restored full precision with a better algorithm (https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/layout/layout_shift_region.h).

dbaron commented 5 years ago

That seems like a reasonable response to me -- probably one that's worth documenting explicitly.

(Having a second implementer might also lead to it changing a bit too...)

skobes-chromium commented 5 years ago

https://github.com/WICG/layout-instability/commit/0fea94ba4dd4b26838e0c30cb09303be2ea17afb