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