[css-contain-2] Allow scroll position to be restored when element becomes un-skipped with content-visibility

[vmpstr]

This depends on #5868. If we agree that skipped contents should not contribute to the overflow (i.e. that the scroll thumb does not indicate size of content), then it would still be nice if we allow for that scroll position to be restored when the element is un-hidden.

The current spec compliant behavior (if #5868 is resolved not to include contents in overflow) would cause the scroll offset to be essentially reset when the element is hidden via content-visibility and then shown again. This is not as ergonomic for developers as it could be.

[flackr]

At a high level this makes sense, but a few thoughts come to mind which may complicate the design of this.

It seems as though you should be able to query the offset (e.g. scrollTop and scrollLeft) and size (scrollHeight and scrollWidth) forcing a layout if these are no longer fresh. This is similar to querying the bounds of an element within the display locked tree.

When contents change I think we should be as consistent as possible with the behavior where the tree is not locked. I.e. with scroll anchoring we would attempt to anchor to the element at the top of the scroller. I think the same should happen here, where we anchor to the last element that was at the top of the scroller when it was locked.

[vmpstr]

It seems as though you should be able to query the offset (e.g. scrollTop and scrollLeft) and size (scrollHeight and scrollWidth) forcing a layout if these are no longer fresh. This is similar to querying the bounds of an element within the display locked tree.

I think if we resolve the other issue to not add overflow here, then these can just return 0 (or whatever is the appropriate default without forcing the layout), right?

When contents change I think we should be as consistent as possible with the behavior where the tree is not locked. I.e. with scroll anchoring we would attempt to anchor to the element at the top of the scroller. I think the same should happen here, where we anchor to the last element that was at the top of the scroller when it was locked.

I think this may be overkill. I agree conceptually that it would be the best thing to do, but the scroll anchoring algorithm is pretty complicated and if we also have to do it on items that are actually not visible (under content-visibility), and not even rendered, I suspect that we would defeat a lot of the optimizations that we can have. WDYT?

[flackr]

It seems as though you should be able to query the offset (e.g. scrollTop and scrollLeft) and size (scrollHeight and scrollWidth) forcing a layout if these are no longer fresh. This is similar to querying the bounds of an element within the display locked tree.

I think if we resolve the other issue to not add overflow here, then these can just return 0 (or whatever is the appropriate default without forcing the layout), right?

They can, it's just very special cased behavior. For most display locked content it is as if we simply skipped the rendering, but it still returns the correct values if queried, so to extend that to the scrollable content it would make more sense if these values were considered part of the "hidden" subtree - i.e. updated if queried but otherwise not visible from the outside effectively moving the scrolling content inside the "contained" subtree.

When contents change I think we should be as consistent as possible with the behavior where the tree is not locked. I.e. with scroll anchoring we would attempt to anchor to the element at the top of the scroller. I think the same should happen here, where we anchor to the last element that was at the top of the scroller when it was locked.

I think this may be overkill. I agree conceptually that it would be the best thing to do, but the scroll anchoring algorithm is pretty complicated and if we also have to do it on items that are actually not visible (under content-visibility), and not even rendered, I suspect that we would defeat a lot of the optimizations that we can have. WDYT?

We wouldn't run anchoring while the contents were hidden, but rather save the anchor node before hiding, and then restore it after the content is no longer hidden, effectively treating the entire duration while the scrollable content was hidden as if it was a single layout update.

[vmpstr]

They can, it's just very special cased behavior. For most display locked content it is as if we simply skipped the rendering, but it still returns the correct values if queried, so to extend that to the scrollable content it would make more sense if these values were considered part of the "hidden" subtree - i.e. updated if queried but otherwise not visible from the outside effectively moving the scrolling content inside the "contained" subtree.

I think we have one of these options:

1. Empty scrollbar + returns updated scrollHeight
2. Empty scrollbar + returns 0 scrollHeight
3. Non-empty scrollbar + returns updated scrollHeight

(Non-empty scrollbar + returns 0 scrollHeight doesn't really make sense)

If we're in either 1 or 2, then I feel like returning updated height is not correct since visually it's an empty scrollbar. If we are to return an updated height, then I would imagine we want a non-empty scrollbar, no? In that case, we of course would be in trouble because we either always have to keep it updated or risk exposing when contents are updated.

Honestly, I don't think this is a big issue in terms of actual use-cases. I agree we should do something that makes sense, so if an empty scrollbar with an updated scrollHeight is the best thing we can expose, then I don't mind. I buy your argument that it is more consistent with the fact that we return proper sizes for elements of this subtree.

We wouldn't run anchoring while the contents were hidden, but rather save the anchor node before hiding, and then restore it after the content is no longer hidden, effectively treating the entire duration while the scrollable content was hidden as if it was a single layout update.

The candidate selection is also not trivial, but doable. I would say that we still want to 1. restore the scroll offset and then maybe 2. do the scroll anchoring adjustment, since it's possible that the anchor element is gone and it's also possible that we couldn't select a viable candidate. IOW if it's gone or wasn't available to begin with, I wouldn't want the scroll offset to be reset to 0. That seems like a weird experience that sometimes we restore the scroll offset and sometimes it's 0 depending on which element is removed and which candidate we picked for anchoring.

That being said, I think just restoring the scroll offset gets us 90+% of a good experience and adding a scroll adjustment after that might not be worth it?