[scroll-animations-1] view timeline insets

[kevers-google]

In scroll-animations-1/rewrite, the inset value is specified as:

[ auto | | {1,4} ]

Since currentTime is tied to the scroll position along a single axis, 2 of the insets are superfluous. Perhaps the insets should correspond to logical start and end, respectively, or both in the case of a single value in the list. This would leave us with only 2 longhands: inset-start and inset-end, which seems reasonable.

[kevers-google]

In https://drafts.csswg.org/scroll-animations-1/rewrite#view-timeline-inset, percent insets are proportional to the size of the scrollport rather than the subject. It is unclear to me which is more useful; however, an effect proportional to the size of the scrollport can be readily achieved by adding keyframes to an animation, but there is no counterpart based on the size of the subject.

[flackr]

In https://drafts.csswg.org/scroll-animations-1/rewrite#view-timeline-inset, percent insets are proportional to the size of the scrollport rather than the subject. It is unclear to me which is more useful; however, an effect proportional to the size of the scrollport can be readily achieved by adding keyframes to an animation

While possible, it's an awkward API to require offsetting the specified keyframes. It seems reasonable to support this use case.

but there is no counterpart based on the size of the subject.

view-timeline-inset is designed to be similar to scroll-padding. We could probably add something similar to scroll-margin for an element size proportional offset, though I'm not sure what the canonical name would be. Regardless, this feels as though it should be a separate issue.

Having only the start and end insets seems reasonable to me for the single animation per insets case where the timeline only conceptually operates along one axis or the other. I suppose a counter-example would be if you had a single view-timeline-insets but multiple view-timelines operating on different axes then it might be useful to specify the 4 values once.

[bramus]

multiple view-timelines operating on different axes then it might be useful to specify the 4 values once.

Independent of their axis, each view-timeline would still only need 2 linked values (or auto), no?

E.g.

el {
  view-timeline: tl1, tl2, tl3;
  view-timeline-axis: block, inline, block;
  view-timeline-inset: 10% 10%, auto, 25% 25%;
}

[fantasai]

I left view-timeline-inset as having only one set of insets that pertains to all the view timelines associated with it. That kept it pretty consistent with scroll-padding. But we could split it out as you suggest, instead, and have it be two values per-axis. I'm not sure what's better.

[bramus]

For scroll-padding is makes sense to have 4 values, as you could have 2D-scrolling and want to set all 4. As we’re only looking at one axis at a time here, only 2 values are needed: a start and an end inset (for the targeted axis).

By having only 2 values:

• it’s easy to flip the axis without needing to re-order the insets
• it plays nice with scenarios where authors use an altered the direction or writing mode. The 4 values for scroll-padding are trbl and are not affected by this change, whereas having only 2 inset values would always be one for start and one for the end inset.

Given this, one could say that view-timeline-inset is a shorthand for view-timeline-inset-start and view-timeline-inset-end – cfr. what @kevers-google suggested earlier on

[bramus]

If not too late, I would like to add this to today’s agenda 😬

[css-meeting-bot]

The CSS Working Group just discussed ViewTimeline insets, and agreed to the following:

• RESOLVED: view-timeline-inset takes a comma-separated list of 1 or 2 values, being autos or length-percentage

The full IRC log of that discussion

<TabAtkins> Topic: ViewTimeline insets
<TabAtkins> github: https://github.com//issues/7243
<TabAtkins> bramus: the syntax for view timleine insets is you can have auto or 1-4 insets
<TabAtkins> bramus: but for view timlines you only need 2, basically
<TabAtkins> bramus: what ??? suggested in the issue is to only have two values
<TabAtkins> bramus: so auto, 1 value, or 2 values
<flackr> s/???/kevers
<TabAtkins> bramus: if you only have 2 values, really easy to change the axis
<TabAtkins> bramus: don't need to update the insets
<flackr> q+
<TabAtkins> bramus: it'll always be from beginning to end of targeted axis
<astearns> ack flackr
<TabAtkins> flackr: so for simpliciation i think this is more convenient
<TabAtkins> flackr: but if you had more than one viewtimeline, i wonder if it's convenient to specify the insets in terms of block and inline, and not worry about whether each timeline was block or inline direction
<TabAtkins> flackr: bc just having two values, we'd reinterpret based on direction of the timeline
<TabAtkins> bramus: suggesting diff properties based on axis?
<TabAtkins> flackr: It's already targeting axises, not timeline axis
<TabAtkins> flackr: so no change would do it
<TabAtkins> fantasai: two ways
<TabAtkins> fantasai: 1) treat like scroll timeline, doesn't matter what direction, one set of padding that applies to everything
<TabAtkins> fantasai: should probably rename to view-timeline-padding in that case
<TabAtkins> fantasai: 2) separate set of insets per timeline, comma-separated of start/end insets
<TabAtkins> fantasai: could have four insets per thing, and only two would apply to a timeline
<TabAtkins> fantasai: seems excessive
<TabAtkins> fantasai: not sure what's more ergonomic for authors
<TabAtkins> fantasai: insets per timleine, or padding that applies to everything at once
<TabAtkins> fantasai: one of the values is auto, where we just copy the value from scroll-padding
<TabAtkins> fantasai: being able to flip that on and off easily is probably useful
<TabAtkins> fantasai: but as for which direction is better overall, dunno
<flackr> qq+
<TabAtkins> fantasai: might require some amount of experience using this feature to know what's better
<astearns> ack flackr
<Zakim> flackr, you wanted to react to flackr
<TabAtkins> flackr: given you can copy scroll padding, which is 4-axis, i'd propose doing a 2-axis specific to the timeline is most ergonomic
<TabAtkins> flackr: If you wanna specify something that applies to all you can use scroll-padding, and this allows you to do a specific override
<TabAtkins> fantasai: scroll-padding has many effects tho
<TabAtkins> flackr: right, but if these are things that conceptually apply to all elements (including scrolling timelines), it should apply
<TabAtkins> fantasai: hm unsure of initial value - do we think people want them to start in the scroll padding, or when visible on page? initial should maybe be zero
<TabAtkins> flackr: I'd think scroll-padding is for if somethin's obscuring the top of the screen
<astearns> initial value 0? https://drafts.csswg.org/scroll-animations-1/#view-timeline-inset
<TabAtkins> fantasai: one use, but not all - might want a #target to have some breathing room, or PgDn to have some overlap
<TabAtkins> fantasai: so defualt in browsers is to include some overlap; scroll-padding lets your control it
<TabAtkins> fantasai: so many uess other than sidebar
<TabAtkins> fantasai: can also use it for the sidebar, because you want similar reasons
<TabAtkins> flackr: I think the overlap use-case is an important separate use-case, but i guess that's a different discussion
<TabAtkins> flackr: but i'm okay with the default not including scroll-padding
<TabAtkins> fantasai: yeah so that's the current initial value
<flackr> For example intersection observer might want to care about sidebar obscured content
<TabAtkins> fantasai: so what's more ergonomic for the author - something analogous to scroll-padding that sets all four edges, or separate insets per timeline, so ti's a comma-separated list
<TabAtkins> fantasai: can see either direction
<TabAtkins> flackr: I think per-timeline is more flexible
<TabAtkins> flackr: might be cases where different animations want different insets
<fantasai> TabAtkins: summary seems to be that view-timeline-inset should be a comma-separate inset of pairs
<fantasai> s/inset of/list of/
<fantasai> flackr: can be single value
<fantasai> TabAtkins: yeah, singles get duplicated
<fantasai> https://github.com//issues/7243#issuecomment-1157679915
<fantasai> view-timeline-inset: 10% 10%, auto, 25% 25%;
<TabAtkins> astearns: would that still allow the escape hatch that bramus mentioned, of making a shorthand that gives start/end in four values
<TabAtkins> fantasai: We could do longhands but I seriously doubt people want them to cascade independent
<TabAtkins> astearns: so auto/1/2 values now, can do 4 values later
<TabAtkins> bramus: or add longhands
<TabAtkins> astearns: that's the distinction, we can do longhands *or* more values
<TabAtkins> flackr: wait we coudln't do 4 values, that would be inconsistent
<TabAtkins> TabAtkins: right, 2 vs 4 wouldn't expand in the normal way
<TabAtkins> astearns: so we're okay with auto/1/2 for now?
<TabAtkins> astearns: so proposed resolution is view-timeline-inset to accept [auto | <length-percentage> ]{1,2}
<TabAtkins> fantasai: and scroll-padding is copied over if you say auto, no change from current
<TabAtkins> RESOLVED: view-timeline-inset takes a comma-separated list of 1 or 2 values, being autos or length-percentage
<TabAtkins> flackr: relatedly we might want to do view-timeline-margin at some point
<TabAtkins> bramus: and whether %s are against the scroller or the element
<TabAtkins> bramus: that's a separate issue

[fantasai]

Fixed in ef3090a