[scroll-animations-1] Interaction of content-visibility: auto and ScrollTimeline.currentTime

[ydaniv]

When using content-visibility: auto some of the content below the fold may have a temporary height, and therefor scroll position, and consequently ScrollTimeline.currentTime will be temporary, until scrolled to that content and will result in a jump in scroll progress, probably resulting in a jump in both currentTime and animation's progress.
I'm assuming this is expected behavior.
Is this something that can somehow be avoided/optimized by the UA? Or worked around by the author?

[ydaniv]

I'm kind of feeling this will be a foot-gun that can be avoided.
Perhaps it's safe to assume that the scrolling experience in this case should win over the loading experience - which is only optimized here.
Is it possible for the UA to detect whether an optimized element is a descendant of a ScrollTimeline.source, and in that case opt-out of optimization?

[css-meeting-bot]

The CSS Working Group just discussed c-v:auto and scrollTimeline.currentTime, and agreed to the following:

• RESOLVED: close no change

The full IRC log of that discussion

<TabAtkins> Topic: c-v:auto and scrollTimeline.currentTime
<TabAtkins> github: https://github.com//issues/7545
<TabAtkins> ydaniv: c-v:auto optimizes experience of mostly loading time
<TabAtkins> ydaniv: UA can handle internally
<flackr> q+
<TabAtkins> ydaniv: if there is a scroller that might change height during scroll, because content with c-v:auto comes into view and expands, it can change currentTime and cause jumps
<bramus> q+
<TabAtkins> ydaniv: so maybe if UA can detect that c-v:auto is being used in a scroller serving as a timeline, do less of this optimization so there's no surprises
<emilio> q+
<astearns> ack flackr
<TabAtkins> flackr: I think this would be a big perf footgun
<TabAtkins> flackr: I think having that disconnect is consistent with what the dev observes thru scrollOffset, so it's not surprisig to me
<TabAtkins> flackr: but if we are concerned, could imagine using c-i-s rather than real size
<bramus> q-
<TabAtkins> emilio: Yeah seems weird to opt out of c-v:auto
<TabAtkins> emilio: author can do that themselves
<TabAtkins> emilio: side effect si unfortunate, but would rather do it rather than add a footgun where your page is all c-v:visible bc you put an animation on the root scroller
<TabAtkins> TabAtkins: details on c-i-s?
<emilio> ack emilio
<TabAtkins> flackr: Like calculate scrollable area as if everything was its c-i-s size. different version of scrollTop/Height
<TabAtkins> emilio: seems tricky
<TabAtkins> flackr: Yeah very tricky, unsure if even possible
<TabAtkins> emilio: would need to do a pass on the contents of the scroller...
<TabAtkins> emilio: i'd rather not
<TabAtkins> flackr: i'd rather if we did that we did it more generally, actually change scrollTop/etc that way
<TabAtkins> iank_: agree, that's a can of worms we dont' want to do
<TabAtkins> astearns: so it sounds like response so far is close no change. that all right with you, ydaniv?
<TabAtkins> ydaniv: yeah
<TabAtkins> RESOLVED: close no change