[pointer-animations-1] Pointer timeline ranges

[ydaniv]

This issue presents a new named animation ranges defined in the Pointer-driven animations spec, and builds on top of the concept of Timeline Ranges defined in scroll-animations-1, plus the concept of Animation Range Centering.

---

Pointer-driven animations introduce new timeline ranges to allow control over the size of the active range, and the interpolation behavior of the timeline, when used together with animation range centering, i.e. the animation-range-center property. These ranges replace the named ranges introduced in Scroll-Driven Animations, with ranges that are more fitting and appropriate for Pointer-Driven Animations.

The spec currently defines the following range names:

fill

• 0% - start padding edge of the element’s principal box.
• 100% - end padding edge of the element’s principal box.
• If center is shifted, then interpolations between 0%-50% and 50%-100% are scaled up/down to fit these ranges.

Example

fit

• Same size as fill
• The 0% and 100% points are offset according to the value of the animation-range-center property, so that the point of 50% remains at the center of the range.

Example

cover

• Largest possible range that fully covers the element’s principal box according to the value of animation-range-center.
• The farthest side from any padding edge to the 50% point is used, and then that side is mirrored to the other side.

Example

contain

• Largest possible range that is fully contained within the element’s principal box according to the value of animation-range-center.
• The closest side from any padding edge to the 50% point is used, and then that side is mirrored to the other side.

Example

---

Note: It's imperative that ranges are first centered according to animation-range-center, and only then -start and -end ranges are applied to expand/contract the active range, as well as adjust interpolation (where necessary) between edges and the 50% progress point.

---

Proposal:

I think we have 3 options here:

1. Accept the above ranges as specced.
2. It seems to me that mixing different ranges together doesn't really make any sense, so we could improve this in 2 ways:
   1. Allow a single range name for PDAs, so that we only have: <range-name> || <range-start-offset> <range-end-offset>?, and we figure out the longhands for that.
   2. Split the above ranges into more basic start/end edges as: farthest-side, closest-side, and fixed. Then the above becomes:
      • cover -> farthest / farthest.
      • contain -> closest / closest.
      • fill is sort of magical here since it allows automatic flipping between farthest / closest and closest / farthest, the idea is that the offsets are relative to the edges.
      • fit doesn't conform to these names - in this range the edges of the range aren't fixed to the edges of the timeline, instead the distances are fixed and offsets are relative to them.

I think I'm leaning towards 2i. - Allowing a single range name for PDAs. IMO these effects usually have a notion of spatial symmetry to them, so splitting the range to start and end doesn't make much sense in the context of PDAs. On top of that, I think the suggested ranges cover well beyond all the use-cases I could find/imagine.

/cc @flackr @fantasai @bramus

[css-meeting-bot]

The CSS Working Group just discussed [pointer-animations-1] Pointer timeline ranges.

The full IRC log of that discussion

<kbabbitt> ydaniv: pointer animations, considering what I said about effects usually used for pointer animations
<kbabbitt> ... require something different
<kbabbitt> ... no concept of entyr and exit for pointer animations
<kbabbitt> ... in the issue itself I listed drawings
<kbabbitt> ... and listed the 4 suggested ranges
<kbabbitt> ... which is basically everything I could think of that we could possibly want to have
<kbabbitt> ... open to suggestions, thjis is what I started with in spec
<kbabbitt> ... I put labels, what is viewport timeline and target
<kbabbitt> ... outer one is viewport, all these examples use an element as timeline, and then target element
<kbabbitt> ... so ranges I suggested are: fill
<kbabbitt> ... just use the 0 as startinh edge of timeine, 100% as end edge of timeline
<kbabbitt> ... and if you specify a center that is not the normal center, not the source 50%
<kbabbitt> ... then it would squish
<kbabbitt> ... the interpolation
<kbabbitt> ... between 50 and 0 and 50 and 100
<kbabbitt> ... just fill that space
<flackr> q+
<kbabbitt> ... concept of this name is somewhat taken from object-fit
<kbabbitt> astearns: coming from discussion earlier, fill is the version that does squish portions of the timeline
<astearns> ack flackr
<kbabbitt> ... but the only one
<kbabbitt> flackr: do you have examples where fill or cover which both change the rate of progression
<kbabbitt> ... are desirable
<kbabbitt> ... in my mind, I only imagined fit as the thing everyone would want
<kbabbitt> ydaniv: I didn't cover the rest of them, but we used only cover
<kbabbitt> ... so that you always get a timeline covering the whole possible area
<kbabbitt> astearns: clarification: cover does not change the rate of progression, it only changes the effective range where th eanimation happens?
<kbabbitt> flackr: if you have multiple targets and one results in cover being larger than the other the rate of animation is different between the targets
<kbabbitt> ... for a single animation the rate is constant
<kbabbitt> astearns; but it can cjhange between different subjects
<kbabbitt> ydaniv; depends on the effect you want. if you want a lot of elements in different places to act together then maybe you'd use different range
<kbabbitt> ... but what we shipped to users was just cover
<kbabbitt> ... which was mostly what everyone wanted
<kbabbitt> ... there were no complaints
<kbabbitt> ... it could change if you use the viewport as your timeline
<kbabbitt> ... then as you scroll and then move your pointer it does change the interpolation range
<kbabbitt> ... because suddenly one end is closer to yout 50% point
<kbabbitt> ... and at another point of the scroll it could be another end
<kbabbitt> ... so it does change interpolation as you scroll
<kbabbitt> ... but all these effects used delaued timeline
<kbabbitt> ... with transitoins and polyfill it doesn't jump
<kbabbitt> ... visually
<kbabbitt> ... you scroll and of course when you scroll the browser stll doesn't update pointer position until you move pointer
<kbabbitt> ... and then range needs to be recalculated
<kbabbitt> ... and you get transition effect to new position
<kbabbitt> .... these cases where you have ... it couldf be also if timeline is an element and it's fixedpos
<kbabbitt> flackr: with fit, this requires that the rate of progression is different on either side of the midpoint
<kbabbitt> ... currently the way animation-range works
<kbabbitt> ydaniv: with cover it's not
<kbabbitt> ... with cover it's always mirrored
<kbabbitt> flackr: with fill, this is not currently supported by the calcs we do for animation-range
<kbabbitt> ... the way animation range is applied is we calc a start time and duration for animation
<kbabbitt> ... and it's linearprogression throughout times between start and duration
<kbabbitt> ... so this will require some sort of transformation step
<kbabbitt> ... for how we map animation timeline into progress
<kbabbitt> ... tajht I guess needs to be added to web animations
<kbabbitt> ... not to say it can't be done but adds complexity
<kbabbitt> ... mayube avoid for now
<kbabbitt> ydaniv: we could avoid
<kbabbitt> ... not sure I have use cases for that
<kbabbitt> ... mor necessary ones are the other 3. or fit and cover
<kbabbitt> ... we could start with that
<kbabbitt> flackr: that also maps to image sizing
<kbabbitt> ... we don't have a version of image sizing with asummetric scaling
<kbabbitt> ydaniv: maps to stretching but not automagic
<kbabbitt> ... I'm fine with dropping it for first version
<kbabbitt> flackr: that reminds me of why I was thinking diff scales could be problematic
<kbabbitt> ... if we apply cover ... cover applies per-axis
<kbabbitt> ... becuse those are independend pointer timelines
<kbabbitt> ydaniv: yes
<kbabbitt> flackr: so you can end up with one ofyour axes changing faster than the other if you were trying to coordinate an effect between those 2 things
<kbabbitt> ... I assume in practice it hasn't been a problem?
<kbabbitt> ... for example ifyour taget element is centered horizontally but is vertically near bottom of viewport
<kbabbitt> ... whje you move pointer horizontally yuou preogress quickly through horizontal effect
<kbabbitt> ... but vertical effect will be slower apparently
<kbabbitt> ydaniv: that's ok
<kbabbitt> ... as long as I control centering of both of them it's expected that effect is porportional to that range
<kbabbitt> ... because that's what you asked for
<kbabbitt> ... if you don't want that to change according to position, you'd need to use a container
<kbabbitt> ... and then that would say, the rate of change would be static
<kbabbitt> ... not as if they used entire viewport
<kbabbitt> ... and as you scroll you get different interpolations
<kbabbitt> flackr: ok
<kbabbitt> ydaniv: for what we shjipped we used the viewport ,nobody complained
<kbabbitt> ... agree there are many use cases fo rjust a container
<kbabbitt> ... certain point where timeline activates
<kbabbitt> ... don't have visual distinction
<kbabbitt> ... depends on your design
<kbabbitt> astearns: are we arriving at a proposed resolution that we accept only the fit and cover ?
<kbabbitt> ydaniv: and contain?
<flackr> q+
<kbabbitt> ... not sure if it's really about use cases for it, but contain is like instead of using farthest as reference point, search for closest edge
<kbabbitt> ... and then mirrors that
<astearns> ack flackr
<kbabbitt> flackr: the last point, not objecting
<kbabbitt> ... this is basically the equivalent of animation-duration
<kbabbitt> ... would it make sense to put these keywords on animation-duration instead?
<kbabbitt> ... what this is calculating is the duration of the animation
<kbabbitt> astearns: what does animation-duration currently take?
<kbabbitt> flackr: auto or <time>
<kbabbitt> astearns: ok
<kbabbitt> ydaniv: one problem I wanted to raise
<kbabbitt> ... proposal has something like 3 options
<kbabbitt> ... as I wrote this issue, I realized this doesn't really map well with start and end range
<kbabbitt> ... more of a range span
<kbabbitt> ... because you don't want to set this independently for start and end
<kbabbitt> ... silly to have cover 0% and then contain 100%
<kbabbitt> ... it's more of just give me a span
<kbabbitt> ... so maybe the solution would be to move this somehow into duration
<kbabbitt> flackr: I understand it may sound awkward, but that is what it is calculating
<kbabbitt> ... we should also consider how this would interact with a specified value for range start instead of range center
<kbabbitt> ... if I have a range start specified, it might also make sense to have a duration that fits to different meanings
<kbabbitt> ydaniv: one option in the proposal is maybe instead of cover and contain, use farthest and closest
<kbabbitt> ... but again I don't find it very useful
<kbabbitt> ... will also cause squishing of timeline
<kbabbitt> astearns: only if you don't use symmetrical ??
<astearns> s/??/start and ends/
<kbabbitt> ydaniv: and I'd rather have one word like range span to alway srestrict using something
<kbabbitt> ... that controls the entire timeline, like both ranges
<kbabbitt> ... so instead of whole timeline, emerging pattern is, you have span and centering
<kbabbitt> astearns: you say emerging pattern, others would say not following convention
<kbabbitt> flackr: it's just that the thing this span is calculating is the length of the animation
<kbabbitt> ... it is duration and it feels we should avoid an additional property
<kbabbitt> ... and maybe add values to duration property
<kbabbitt> ... keywords sound fine to me, cover and contain
<kbabbitt> ... those have a lot of value and do map to analagous concepts
<kbabbitt> astearns: I like this direction but would like to see how it all fits with what we have now
<kbabbitt> ... and have the meanings of these keywords defined for other timelines
<kbabbitt> flackr: and for specifying start or end instead of center
<kbabbitt> ... because essentially you're setting up 2 of 3 constraints on an animation and calculating the third
<kbabbitt> astearns: would it be oka to take this back to issue and see if it can beshoehorned into duration?
<kbabbitt> ydaniv: sure
<kbabbitt> astearns: then let's do that but I am much happier with my undestanding of pointert animations given this discussion, thank you
<ydaniv> scribe+