[css-scroll-anchoring] Consider invalidating anchor after adjustment if at the point of selection the anchor has dirty descendants

[emilio]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1738781 for context.

At first I thought that the test-case there behaving suboptimally was a Firefox bug, but after more investigation I think it's a Chromium bug instead (see https://bugzilla.mozilla.org/show_bug.cgi?id=1738781#c2 and following).

I think we could consider invalidating the anchor after applying an adjustment if when we selected the anchor there were dirty children. This will guarantee a better anchor regardless of focus moving or what not. Blink implements something like that already for content-visibility: auto.

cc @chrishtr @vmpstr

[flackr]

This sounds like a good change to me.

For the particular test case, I think another option would be to trigger invalidation after adjustment when the previous anchor node was removed, however I think your suggestion generalizes better.

[chrishtr]

I think we could consider invalidating the anchor after applying an adjustment if when we selected the anchor there were dirty children.

What does dirty mean in this case? For content-visibility:auto we the trigger is "skipped" (a spec term), not dirty. What would we use in other cases?

[emilio]

Yeah, I guess defining it might be problematic because "dirty" for our purposes is "has children that may need layout". However I wonder if it is observably different to always invalidating the anchor after adjustment? If there's no layout changes under the anchor's subtree, the anchor should be unchanged, right?

[chrishtr]

However I wonder if it is observably different to always invalidating the anchor after adjustment? If there's no layout changes under the anchor's subtree, the anchor should be unchanged, right?

This sounds right to me...