layout-instability icon indicating copy to clipboard operation
layout-instability copied to clipboard

exclude elements that transition from hidden to visible

Open skobes-chromium opened this issue 5 years ago • 4 comments

The spec currently excludes visibility:hidden elements from the unstable node set, but it doesn't exclude elements that are now visibile but were hidden in the previous frame.

We should exclude such elements for the same reason that we exclude visibility:hidden generally. A visible shift requires visibility in both the previous and current states. Transitioning from hidden to visible is more like inserting new content, which CLS intends to allow.

crbug.com/1152869

skobes-chromium avatar Dec 09 '20 00:12 skobes-chromium

How about defining visual representation as: visible ink overflow [1]?

  • It excludes invisible things
  • (unrelated to this bug, but is a (good?) side-effect of using visible ink overflow) It includes visible ink overflows, e.g. outlines, shadows. Though their change don't trigger layout shift, they contribute to visual change. For example, we still don't record a layout shift for
  <div id="target" style="..."></div>
  <script>setTimeout(() => {target.outline = "10px solid blue";}, 1000);</script>

but will record a layout shift for

  <div id="target" style="width: 1px; height: 1px; outline: 100px solid blue; margin: 100px"></div>
  <script>setTimeout(() => {target.style.marginTop = '300px';}, 1000);</script>

Note that Chrome is already using ink overflow for visual representation.

[1] https://drafts.csswg.org/css-overflow-3/#ink-overflow

wangxianzhu avatar Dec 14 '20 17:12 wangxianzhu

I think it is better that we don't report a layout shift for outline and shadow changes. We used to do this, but it often fired on pages with hover effects, which wasn't really intended.

skobes-chromium avatar Dec 15 '20 19:12 skobes-chromium

No, I'm not suggesting reporting layout shift for outline and shadow changes, but suggesting considering ink overflow when the object shifts. Please see the examples: example 1 shows what we don't want to report, while example 2 shows what Chrome is reporting and what I suggest to modify the spec. Specifically, for example 2, Chrome is reporting a shift of 201x201 by 200 (which reflects user experience), instead of 1x1 by 200 (which will be ignored).

In other words,

  1. Distance of layout shift is the distance of starting point movement, which is not affected by outline and shadow changes.
  2. The affected area of layout shift should consider all moved pixels, including ink overflows, which reflects user perception.

wangxianzhu avatar Dec 15 '20 19:12 wangxianzhu

Ah I see, thanks for clarifying. This proposal sounds good to me.

skobes-chromium avatar Dec 15 '20 19:12 skobes-chromium