exclude elements that transition from hidden to visible

[skobes-chromium]

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

[wangxianzhu]

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

[skobes-chromium]

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.

[wangxianzhu]

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.

[skobes-chromium]

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