[pointer-animations-1] Animation range centering

[ydaniv]

This issue presents a new concept defined in the Pointer-driven animations spec, and enhances the concept of Timeline Ranges defined in scroll-animations-1.

Context

It's common for pointer-driven animations to shift the center of the attachment range - the point of 50% progress - to a specific point, so that common animations with an effect’s progress of [1, 0, 1] or [-1, 0, 1] always reach 0 on that specified point.
Usually that point is relative to the animated element, the animation's target, rather than the timeline’s subject element. Usually it's the animation target's center.
The important thing to note here is that while the range is defined relative to the timeline’s subject element, the shift of the range's center may be defined relative to the animation’s target - so that range start/end are relative to one element, and centering is relative to another.

Proposal

Define a new property: animation-range-center, which is a new sub-property of animation-range, that allows specifying that centering point. This property takes either a <length-percentage> and/or a keyword to represent choosing between the timeline’s subject and the animation’s target.
The <length-percentage> specifies the offset from the subject element’s principal box’s start padding edge.

That keyword can have one of the following values:

• source: The element whose pointer offset drives the progress of the timeline.
• target: The element to which the animation is applied.

Note: in cases where target is used, the point of 50% progress can be outside the 0-100% progress range. In such cases, the animation attachment range is cut off at the 50% progress point.

/cc @fantasai @flackr @bramus

[css-meeting-bot]

The CSS Working Group just discussed [pointer-animations-1] Animation range centering, and agreed to the following:

• RESOLVED: Add this property with syntax described here and normal as default value

The full IRC log of that discussion

<kbabbitt> ydaniv: second issue is about a new concept for range centering
<kbabbitt> ... that is very common for pointer effects, pointer animations
<kbabbitt> ... because usually the effects timeline goes from 1 to 0 in 50% progress and then back to 1
<kbabbitt> ... or -1 to 0 and then to 1
<kbabbitt> ... so you have sort of symmetry or reverse symmetry in the effects usually
<kbabbitt> ... and what you usually want to do is specify where is the focal point of the effect
<kbabbitt> ... where is the 50% progress of the timeline
<kbabbitt> ... so that the effect gets sync'ed to that 50% progress
<kbabbitt> ... and so the order of operations is that you have the full timeline and then you center it
<kbabbitt> ... and then you apply the ranges
<kbabbitt> ... which is the next topic
<kbabbitt> ... this is first about centering
<kbabbitt> ... what pointer animations introduce is first that animation range center
<SebastianZ> q+
<kbabbitt> ... subproperty that allows you to center the range
<kbabbitt> ... or define center of timeline
<kbabbitt> ... and that by default is relative to the source of the timeline
<kbabbitt> ... element or viewport
<kbabbitt> ... but you can also specify that this is done relative to target element of animation
<kbabbitt> ... so you have a length-percentage to define the centering and also a keyword to say source or target
<kbabbitt> ... this is also very common to pointer animations
<kbabbitt> ... where you could have 1 element that defines range
<kbabbitt> ... say a whole section
<kbabbitt> ... could take full viewport
<kbabbitt> ... and you want the timeline to span the entire section
<kbabbitt> ... but you want the effect on let's say 1 image in that section
<kbabbitt> ... you want effect to center when pointer is centered on that image
<kbabbitt> ... but have 100% span entirety of section
<kbabbitt> ... or to other side
<flackr> q+
<kbabbitt> ... so this is basically the proposal
<kbabbitt> ... to add this to the spec and add animation-range-centered property
<kbabbitt> ... which takes length-percentage and keyword source or target
<kbabbitt> ... defaults to source
<kbabbitt> ... the length-percentage defaults t 50%
<kbabbitt> ... so if you omit this it just uses the middle point of the timeline
<kbabbitt> ... and you can just say target and it will use center of target
<astearns> ack SebastianZ
<kbabbitt> SebastianZ: thinking about that I was actually thinking about an origin
<kbabbitt> ... like we have for transform-origin
<kbabbitt> ... so it would basically be the same but I would name it like animation-range-origin
<kbabbitt> ... and mimic something like transform-origin
<kbabbitt> ... my idea was to reuse the position data type
<kbabbitt> ydaniv: the thing is we specify where the 50% progress goes
<kbabbitt> ... where do we have 50% progress
<kbabbitt> ... we already have range-start and range end
<kbabbitt> ... adding range origin
<kbabbitt> SebastianZ; yes, range origin will just say where you put the origin of your range
<kbabbitt> ... could be negative
<kbabbitt> ydaniv: it's not 0, oit
<kbabbitt> ... 's 50%
<kbabbitt> ... though we have symmetry, sometimes reversed symmetry
<kbabbitt> SebastianZ: still inclined to call it origin
<kbabbitt> ydaniv: open to bikeshedding
<kbabbitt> SebastianZ; maybe another name pointing out focal point of animation
<kbabbitt> ... then use position value for that
<kbabbitt> ... and keyword for saying source or target
<kbabbitt> astearns: I have reservations about both of those ideas
<astearns> ack flackr
<kbabbitt> flackr: question also a concern
<kbabbitt> ... if you have a target that's not 50%, is the animation you get asymmetric?
<kbabbitt> ... faster on one side slower on other?
<kbabbitt> ydaniv: something that you then control with ranges
<kbabbitt> flackr: but what if I don't set any ranges?
<kbabbitt> ... centering implies that you're shifting
<kbabbitt> ydaniv: depends on default pf ranges. tjat
<kbabbitt> ... 's next issue
<kbabbitt> ... if we use fit range by default, it will take full size of timeline and just shift it
<kbabbitt> ... you'll still have
<kbabbitt> flackr: so they still move at same rate on either side of target
<kbabbitt> ydaniv: yes, different values different ranges to keep interpolation similar on both suides
<kbabbitt> ... there's another one that allows you to squish it
<kbabbitt> flackr: ok I;ll have to think about it more
<kbabbitt> ... concern is, if you have a single pointer timeline A< and its being used by 2 elements B and C
<kbabbitt> ... and you specify that the center is the target
<kbabbitt> ... then you've set up a situtation where the current time is different for both elements/
<kbabbitt> ... it feels as if you're putting a propertuy in thetimeline that belongs on the animating target
<kbabbitt> ydaniv: no, centering goes on animating target
<kbabbitt> flackr: oh I see, animation range center ok
<kbabbitt> ... ok I understand now other issue you mentioned
<kbabbitt> ... this is setting range usedby that animation
<kbabbitt> ... to be based around that target's position with respect to pointer animation
<kbabbitt> ydaniv: think about a list of cards
<kbabbitt> ... and all of them use
<kbabbitt> ... viewport or container as timeline
<kbabbitt> ... each one of them you want to rotate around Y
<kbabbitt> ... and you want each of them to rotate according to position of the pointer
<kbabbitt> ... around that container
<kbabbitt> ... but each should center when the pointer reaches their own center
<kbabbitt> ... then they all have the same effect, same animation, same ranges
<kbabbitt> ... it just works
<kbabbitt> ... as you hover across them, they all turn towards you or away depending on effect
<kbabbitt> ... as you go on center of each, each completely faces you
<kbabbitt> ... just works out
<kbabbitt> ... this is how pointer effects usually are created
<kbabbitt> astearns: thanks for that. are there other timelines that have this center concept?
<kbabbitt> ydaniv: no
<kbabbitt> astearns: this is new for pointer timelines
<kbabbitt> flackr: this wouldn't have a meaning for other timelines which is okay I guess
<kbabbitt> SebastianZ: astearns you raised concerns about my point/
<kbabbitt> astearns: set of position values used for background positioning
<kbabbitt> ... have detractors
<kbabbitt> ... there are people who don't like them
<kbabbitt> ... I think this is much simpler since we're only talking about a single distance along a known range
<kbabbitt> ... I think it's simpler and better to use a single length-percentage than to reuse position values
<kbabbitt> flackr: the other thing I though tmight be worth mentioning in context of origin discussoin
<kbabbitt> ... we don't have to limit animations to 0-100%
<kbabbitt> ... we could say that setting this origin property is the 0 point
<kbabbitt> ... but the animation range goes negative to positive
<kbabbitt> SebastianZ: did we already take a photo?
<kbabbitt> [referring to previous discussion]
<kbabbitt> ydaniv: idea was to map this to existing ... the way keyframes and animations work today
<kbabbitt> ... and still be able to specify these effects in intuitive form
<kbabbitt> ... and still allow centyering
<kbabbitt> flackr: would 0% being the center be more intuitive?
<kbabbitt> ... we've already allowed keyframes outside 0-100% for view timelines
<kbabbitt> ... because you specify these things relative to offsets of the element
<kbabbitt> ... and you can't guarantee that uathor doesn't specify things outside that range so we've allowed it to work
<kbabbitt> ... this could be a case where it makes sense to embrace this, you can have n egative % on keyframes
<kbabbitt> ydaniv: could work for soe effects
<kbabbitt> ... have to specify what happens wen you go below 0
<kbabbitt> ... rotation maybe you wnt ot go to -1
<kbabbitt> ... other effects you want to mirror what you do
<kbabbitt> ... for example opacity
<kbabbitt> .. go back to 0 again
<kbabbitt> ... depends on effect
<kbabbitt> astearns: something you specify on ranges
<kbabbitt> ydaniv: this is specifyed on ranges and then you need to create an effect
<kbabbitt> ... if 0% is the center, for each effect you need to specify how going below 0 effects it
<kbabbitt> flackr: you'd have a -100% keyfrome or something like htat
<kbabbitt> ydaniv: yes and you'd have very specific effects taht aren't resuable
<kbabbitt> flackr: wouldn't make sense on time based animations
<kbabbitt> ... there are other future animations where values below 0 make a lot of sense
<kbabbitt> ... didn't want design to be constrained to only thinking about 0-100%
<kbabbitt> ... we can allow for negative values
<kbabbitt> ... if that's more intuitive we should consider
<kbabbitt> ydaniv: ok
<kbabbitt> ... also in the spec there's a proposal written how to write this in a shorthand
<kbabbitt> ... so it would look something like
<kbabbitt> ... the at keyword for example
<ydaniv> animation-range: cover at 50% target;
<kbabbitt> ... so you could have ^
<kbabbitt> ... taken this from syntax of gradients
<kbabbitt> flackr: I do like making it part of the animation range
<kbabbitt> ... property
<kbabbitt> ... because then at least it's not a property that only applies to pointer animations
<kbabbitt> ... even though the values only make sense for pointer animations
<ydaniv> q?
<kbabbitt> SebastianZ: still thinking about how this works and what use cases are
<kbabbitt> ... I'm currently implementing the area for the animation being the adding box
<kbabbitt> ydaniv: or border box
<kbabbitt> SebastianZ: or border box
<kbabbitt> ... and you have two different animation axis right?
<kbabbitt> ydaniv: yes
<kbabbitt> SebastianZ: so we're talking about animation range center right now
<kbabbitt> ... what are use cases for those?
<kbabbitt> ... we have 0% of the animation range when ???
<kbabbitt> ydaniv: [missed]
<kbabbitt> SebastianZ: what are use cases for changing cetner of animation range?
<kbabbitt> ydaniv: most use cases require centering
<kbabbitt> SebastianZ: like a parallax effect for example?
<kbabbitt> ydaniv: yes sometimes referred to as mouse parallax
<kbabbitt> ... a lot of the effect is that you have something like a card element
<kbabbitt> ... then it rotates with the pointer
<kbabbitt> ... so you want it to completely face you and not be rotated at all when you're centered on the card
<kbabbitt> ... sometimes you wat timeline to be card itself, sometimes container or entire viewport
<kbabbitt> ... and you still want to see effect ragartless of where you are
<kbabbitt> ... still wnt to keep center of effect which is 0deg rotation in this case
<kbabbitt> ... when pointer is cetnered on animation target
<kbabbitt> astearns; I think SebastianZ was asking when do you want that center to be somehwere other than center of target or source?
<kbabbitt> ydaniv: it's almost always the center
<kbabbitt> ... if it's the target then you would say just "at target" I guess
<kbabbitt> ... most use cases are switching between center of timeline itself, source of timeline, or animationtarget
<kbabbitt> ... could be a bunch of elements and you don't want each one to 0 independently
<kbabbitt> ... you want them to feel like a lot of elements that work together
<kbabbitt> ... all of them 0 when you're in center of timeline
<kbabbitt> ... mostly to switch between target and source
<kbabbitt> ... and I allowed option to also specify different place if you have some special case
<kbabbitt> ... I could just say just keyword source or target
<kbabbitt> ... but then maybe you have some considerations specific to your effect
<kbabbitt> ... you want to just move it around
<kbabbitt> SebastianZ: what I have inmind as use case is letting element follow mouse pointer
<kbabbitt> ... while hovering an element for example
<kbabbitt> ... can that already be achieved with current approach?
<kbabbitt> ydaniv: yes
<kbabbitt> ... if you want element to follow mouse?
<kbabbitt> ... in original issue, I can link the original issue with explainer
<kbabbitt> ... that has this
<kbabbitt> ... an example here
<ydaniv> https://github.com/issues/created?issue=w3c%7Ccsswg-drafts%7C10574
<kbabbitt> ... ^ bad link sorry
<ydaniv> https://github.com//issues/10574
<kbabbitt> ... ^ this one is better
<kbabbitt> ... if you scroll down you'll see an example
<kbabbitt> ... simple example of having an element trace pointer position
<kbabbitt> ... so you need 2 timelines and I'm using animation composition
<kbabbitt> ... to place them together
<kbabbitt> flackr: it's essentially a timeline for each axis with a transform in that axis
<kbabbitt> ydaniv: yes
<kbabbitt> ... so if in this case it could be cover at target cover at target
<kbabbitt> ... the ranges
<kbabbitt> SebastianZ: and it wouldn't necessarily have to be ?? in the example you have
<kbabbitt> ... not necessary to have 50% keyframe
<kbabbitt> ydaniv: yes, it's necessary to specify the ... if 50% computes to 0
<kbabbitt> ... it comes out naturally from the math could remove explicit 50% keyframe
<astearns> s/??/50%/
<kbabbitt> ... could make this even shorter
<flackr> q+
<astearns> ack flackr
<kbabbitt> flackr: I didn't mean to derail this conversation, now that I understand proposal, I think it's workable
<kbabbitt> ... we could start with that and update if we came up with something better
<kbabbitt> ydaniv: ok
<kbabbitt> flackr: and if you can work it in to animation range I'd prefer that over new property
<kbabbitt> ... you mentioned having an animation range syntax but this could be a follow-up proposal
<kbabbitt> SebastianZ: would be great to see a prototype of how it plays together
<kbabbitt> ... still hard to imagine all the different pieces working together
<kbabbitt> ... coud be possible if you created some kind of polyfill to write this out or did you already?
<kbabbitt> ydaniv: yes we shipped this to users at WIX
<kbabbitt> ... currently everything is centered to target, use entire viewport for timeline
<kbabbitt> ... this is default we use for all effects
<kbabbitt> ... exactly what designers and product manager wanted
<kbabbitt> ... everybotyu's happy no complaints
<kbabbitt> astearns: you haven't impl'd target?
<kbabbitt> ydaniv: no jsut the target, everything using target
<kbabbitt> ydaniv: everything using viewport as timeline centered to animation target
<kbabbitt> SebastianZ: do you have demos for your impl?
<kbabbitt> ydaniv: yes showed them in the explainer
<kbabbitt> ... this was already presented
<flackr> https://github.com//issues/10574
<kbabbitt> flackr: there's demos at that link
<kbabbitt> astearns: I am a little concerned about center as the property name here
<kbabbitt> ... but I'm not entirely sure what would replace it. maybe basis?
<kbabbitt> ... because you're choosing a reference
<kbabbitt> ... from which the length-percentage is applied
<kbabbitt> ... in order to select a single point
<kbabbitt> ... on the timeline
<kbabbitt> ... I don't know what to call that
<kbabbitt> ydaniv: ok but it's just bikeshedding?
<kbabbitt> astearns: yes. functionality in thjis makes sense to me, I just think it could probably have a better name
<kbabbitt> ydaniv: ok I think after I present next issue we can think about bikeshedding stuff
<kbabbitt> ... but basically idea is something workable?
<kbabbitt> astearns: I think so
<kbabbitt> [agreement from flackr and SebastianZ]
<kbabbitt> astearns: Proposal is to add property named animation-range-center for now that takes either a length-percentage or a keyword or both
<kbabbitt> ydaniv: yes
<kbabbitt> flackr: or has an initial value that means nothing right
<kbabbitt> ydaniv: accept the spec as-is and bikeshed
<kbabbitt> astearns: spec as is what is default value?
<kbabbitt> ydaniv: I think source 50%
<kbabbitt> ... use what you have on timeline
<kbabbitt> SebastianZ: it's normal, and normal is 50% of animation's active interval
<kbabbitt> flackr: normal was part i was looking for
<kbabbitt> ... don't know what it means for other timelines yet
<kbabbitt> astearns: Proposed resolution: Add this property with syntax described here and normal as default value
<kbabbitt> ... all to be bikeshedded if needed
<kbabbitt> ... objections?
<kbabbitt> RESOLVED: Add this property with syntax described here and normal as default value
<kbabbitt> flackr: I think this concept might be applicable to view timelines
<kbabbitt> ... will have to think about it
<kbabbitt> ... or scroll view timelines
<kbabbitt> ydaniv: with all scroll animations we impl'd they were based on view timelines
<kbabbitt> ... wanted to have user be able to see where their 50% is
<kbabbitt> ... which is the original thing they put in the layout without the effect
<kbabbitt> SebastianZ: if it can be applied to other timelines maybe it should be moved to more generral spec
<kbabbitt> ydaniv: yes