Consider excluding user-scroll + scroll-anchor in the same frame from being penalized

[vmpstr]

From my understanding the instability (shift) is detected by following this rough algorithm:

• if element stuck to viewport (based on prev/new positions), not a shift
• if element stuck to document, not a shift
• if element does anything else, it's a shift

(credit to @skobes)

However, there seems to be another case: an element is stuck to a 'virtual' document whose position is kept intact via scroll anchoring, but it is still able to move around via user scrolls.

As an example, consider content-visibility: auto element that may change size as it leaves the viewport (technically, leaves a padded area that is centered around the viewport). For a sibling element that is on screen two events affect its position:

1. The scroll anchoring effect which ensures that the visible element does not shift position
2. The user scroll that moved content-visibility: auto element off screen in the first place.

The desired net effect here is that the element visually shifts by the user scroll amount from 2. However, here the desired effect is neither "sticking to the viewport" nor "sticking to the document" since both positions shift: viewport position is shifted by user scroll, and document position is shifted by the scroll anchor.

Chromium's implementation of this does report a layout shift. I think we should change this behavior.

As a side note, this is not specific to content-visibility: auto element since the same behavior can be polyfilled with an intersection observer that changes size of elements off screen

[npm1]

Are these cases covered by these changes? https://chromium.googlesource.com/chromium/src/+/main/docs/speed/metrics_changelog/2020_11_cls.md

If so then the implementation has excluded these for a while but I don't think we updated the spec.