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