- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 22:11:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-animations-2][web-animations-2] (proposal) Add pointer driven animations`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> ydaniv: New proposal for pointer-driven animations<br> <TabAtkins> ydaniv: gonna show some examples<br> <TabAtkins> ydaniv: here's one example, parallax driven by pointer<br> <TabAtkins> ydaniv: another example, a whole suite of elements parallaxing<br> <TabAtkins> ydaniv: another example, each element is its own timeline (cards slightly shifting in 3d to avoid the pointer)<br> <TabAtkins> ydaniv: here's something we built internally, using a polyfill<br> <astearns> (example links in the issue)<br> <TabAtkins> ydaniv: (more parallax)<br> <TabAtkins> ydaniv: (a cat watching the pointer)<br> <TabAtkins> ydaniv: [slides times]<br> <TabAtkins> ydaniv: proposal for a pointer-timeline<br> <TabAtkins> ydaniv: driving an animation based on position of the pointer<br> <TabAtkins> ydaniv: relative to a box, or to the screen<br> <TabAtkins> ydaniv: builds on what we already have in scroll-driven animations<br> <astearns> s/screen/viewport/<br> <TabAtkins> ydaniv: some commonf eatures, attachment is usually the box of: animations target, a parent container, or the whole viewport<br> <TabAtkins> ydaniv: effects usually have a focal point, effect range is [1, 0, 1], [-1, 0, 1], or [0, 1, 0]<br> <TabAtkins> ydaniv: focal point is usually relative to the effect's target, or the timeline's subject<br> <TabAtkins> ydaniv: more common features: delayed progress<br> <TabAtkins> ydaniv: progress linked to velocity<br> <TabAtkins> ydaniv: some effects rely on polar coordinates<br> <TabAtkins> ydaniv: proposal is fully bikesheddable, some features are deferable<br> <TabAtkins> ydaniv: new property 'pointer-timeline: <name> <axis>'<br> <TabAtkins> ydaniv: works like view-timeline<br> <TabAtkins> ydaniv: new functional notation for anonymous animations: pointer(<axis> [ self | nearest | root ])<br> <TabAtkins> ydaniv: nearest means containing block of the target<br> <lea> q?<br> <TabAtkins> (because it's anonymous)<br> <TabAtkins> ydaniv: root is the whole viewport. can be a bit tricky, i'll explain later<br> <lea> q+ to ask can we reuse a referencing mechanism from another part of CSS? E.g. anchor positioning<br> <fantasai> suggest using container rather than nearest<br> <fantasai> since nearest parent may not be contianing block<br> <TabAtkins> ydaniv: new range names, entry and exit dont' really make sense<br> <TabAtkins> ydaniv: can keep cover, contain<br> <TabAtkins> ydaniv: propose adding fill and fit, taking from object-fit<br> <lea> Do we have a link to the slides?<br> <TabAtkins> ydaniv: by default the ranges aren't different unless you shift the center of the attachment point<br> <TabAtkins> ydaniv: new property, range-center to set the focal point<br> <TabAtkins> ydaniv: takes <length-percentage> or center/start/end keywords<br> <TabAtkins> ydaniv: can also take normal|target keyword, to target the animation target instead<br> <TabAtkins> ydaniv: have some demos<br> <TabAtkins> ydaniv: [shows off some illustrations]<br> <TabAtkins> ydaniv: in this, the red square is the viewport, bluie is the target, green has pointer-timeline<br> <TabAtkins> ydaniv: non-ancestor relationship, 50% is just in the center of the green<br> <lea> Material buttons are also another use case: clicking on a button grows a highlight from the pointer to the whole button https://m2.material.io/components/buttons<br> <TabAtkins> ydaniv: if blue is an ancestor, center is the center of blue, 0-100% is centered on that<br> <TabAtkins> "contain at target center"<br> <ydaniv> https://docs.google.com/presentation/d/1QwyeTDK8n6RU1px0-iu0Txi2aJH6zTL6d7X6_z-kk4A/edit#slide=id.g3007a239b93_0_79<br> <TabAtkins> ydaniv: "cover at target center", blue's center is still used, then it expands so 0-100 covers the green<br> <TabAtkins> ydaniv: "fill at target center", blue's center is used, but 0-100 exactly fills the green, so 0-50 and 50-100 use different scales<br> <TabAtkins> fantasai: would you want an easing function for that, since you're compressing one side and expanding the other?<br> <TabAtkins> ydaniv: I think you already have the potential for that...<br> <TabAtkins> flackr: I think th e point is your animation keyframes will have a 50% frame, and you can apply easing to work<br> <TabAtkins> fantasai: right, it's just a sharp change from compressed to expanded<br> <astearns> q?<br> <TabAtkins> TabAtkins: but a good easing choice can make that smooth, and making it easier is a separate thing<br> <TabAtkins> ydaniv: "fit at target center", blue center is used, 0-100 range is the *size* of green, but centered on blue<br> <TabAtkins> ydaniv: as you scroll you can stretch/squish the timeline<br> <TabAtkins> ydaniv: already can happen in scroll timelines if fixpos, but here's it's more common<br> <TabAtkins> ydaniv: the way we handle this fact when you're centering at the target is when you're using cover/contain, and your subject is the viewport....<br> <astearns> the pointer-driven timeline shifts at every scroll in that case<br> <TabAtkins> ydaniv: as you scroll, it will change the timeline<br> <TabAtkins> ydaniv: we shipped this to users with the polyfill<br> <TabAtkins> ydaniv: we use scroll-end to recalc the timeline on each scroll<br> <TabAtkins> ydaniv: [shows off "contain at source 200px 200px"] contrived to have a range at a specific point, but possible<br> <TabAtkins> ydaniv: [demo]<br> <TabAtkins> ydaniv: [demo shows off the range results as a gradient when various options are used]<br> <TabAtkins> ydaniv: [recaps the proposal]<br> <astearns> ack lea<br> <Zakim> lea, you wanted to ask can we reuse a referencing mechanism from another part of CSS? E.g. anchor positioning<br> <TabAtkins> lea: is there any way we could harmonize these refs with other parts of CSS?<br> <TabAtkins> lea: anchor-pos allows you to ref other elements<br> <kbabbitt> q+<br> <TabAtkins> lea: also, was wondering, the pointer() function is only available in animations?<br> <TabAtkins> lea: for second, this is just a way to draw animations, like view-timeline and scroll-timeline<br> <TabAtkins> s/lea/ydaniv/<br> <fantasai> s/draw animations/drive animations/<br> <TabAtkins> q+ to respond<br> <kbabbitt> q- later<br> <TabAtkins> ydaniv: the functions are used just for anonymous timelines<br> <TabAtkins> lea: was thinking this seems like a heavyweight solution if all you want is to get the relative position of a pointer for a background<br> <TabAtkins> lea: was wondering if we could add a simple function that gets you the pointer location relative to whatever<br> <TabAtkins> lea: I come across those cases fairly frequently<br> <TabAtkins> ydaniv: I think what you were asking was asked for by Bramus<br> <TabAtkins> ydaniv: it didn't go further, there were some issues?<br> <dbaron> Scribe+<br> <TabAtkins> flackr: we do the same thing for scroll/view timeline<br> <TabAtkins> flackr: they're not exposed as variables to use<br> <TabAtkins> flackr: they can be plugged into animations<br> <TabAtkins> lea: to resolve cycles?<br> <TabAtkins> flackr: not quite, if you have a variable it's non-trivial to know how we can respond to that off the main thread<br> <dbaron> TabAtkins: for now this is intrinsically something that wants to run off main thread, because it's scroll responsive<br> <dbaron> TabAtkins: we've solved that for animations but not the general case<br> <TabAtkins> flackr: if your animation *can* be composited, as long as we can determine the progress on the compositor we can accelerate the whole thing<br> <TabAtkins> flackr: but if it requires animating style we havne't figured that out yet<br> <kbabbitt> q-<br> <flackr> TabAtkins: I also think that one of the progress functions in values and units is meant to address handling an animation locally<br> <dbaron> TabAtkins: I also think one of the progress functions in values and units is meant to address this handling the animation locallly like this. Saying what timeline you want to use, just pops the value right there.<br> <kizu> q+<br> <dbaron> TabAtkins: rather than getting a number directly out of the timeline you can directly ???<br> <astearns> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to respond<br> <dbaron> TabAtkins: I think there is something over there -- fantasai wrote that section.<br> <dbaron> fantasai: are you thinking about progress() and mix() being able to pull a value out of a timeline?<br> <TabAtkins> fantasai: thinking about progress() and mix() functions that Miriam and I proposed could take a timeline<br> <TabAtkins> TabAtkins: yes, the grammar for that is currently in the spec<br> <astearns> ack kizu<br> <TabAtkins> kizu: +1 to this proposal<br> <TabAtkins> kizu: this is something authors want<br> <TabAtkins> kizu: I think animations as a first step is a good idea<br> <ydaniv> this should work: https://docs.google.com/presentation/d/18P_EX0Vy61Fy6iLUPP6YsNIe2GSHmKtiltEabPXhyo0/edit?usp=sharing<br> <TabAtkins> kizu: I've played a lot with events<br> <TabAtkins> kizu: we could do this in a hacky way with view timelines, by getting position as a pixel value<br> <TabAtkins> kizu: I don't know if the proposal allows doing this rather than using the % directly<br> <TabAtkins> kizu: if you want to display something you might just want an offset directly; calculating the offset from a % is possible but would like to avoid it<br> <TabAtkins> (I think you might be able to get that by driving an animation between 0 and anchor-size(), if that's applicable)<br> <flackr> q+<br> <TabAtkins> ydaniv: elaborate?<br> <TabAtkins> kizu: if I want to use this value in other places, like using a % in background. If the % is relative to something *else*, it's not usable directly in backgrounds.<br> <TabAtkins> kizu: We kinda could do in some hacky ways but it's not easy<br> <TabAtkins> kizu: so if the container is 300x300, we'd like a way to access a length like "120px" for 40% progress<br> <TabAtkins> ydaniv: This is using normal animations... basically you just set everything in keyframes<br> <TabAtkins> kizu: I'll comment with details on the issue<br> <TabAtkins> flackr: for mouse it's clear that this represents the hovered position<br> <TabAtkins> flackr: what happens with touch. primary touch point?<br> <TabAtkins> ydaniv: great question<br> <TabAtkins> ydaniv: I have libraries that polyfill this behavior, they each do something different<br> <TabAtkins> ydaniv: one is built to use the gyroscope<br> <TabAtkins> ydaniv: another uses long-press to trigger the animation, then as you drag your touch it moves with your finger<br> <TabAtkins> ydaniv: I think the last one just falls back to hover, so if you tap it'll update<br> <TabAtkins> ydaniv: what we did is just wrap everything in a (hover) MQ, so it's desktop only<br> <TabAtkins> flackr: so it's default to legacy desktop behavior, if you tap it uses that point<br> <TabAtkins> ydaniv: yeah<br> <astearns> ack flackr<br> <TabAtkins> flackr: does this only update when the cursor is within the observation container?<br> <fantasai> slides: https://lists.w3.org/Archives/Public/www-archive/2024Sep/att-0011/CSSWG___TPAC_2024___pointer-timeline.pdf<br> <TabAtkins> flackr: the green boxes<br> <TabAtkins> flackr: if I move my animation out the box on the left side, circle the box, and reenter on the right, is it tracking my pointer the whole time, or updating when it reenters?<br> <TabAtkins> ydaniv: the whole time<br> <TabAtkins> astearns: so I'm assuming this was for socializing the proposal - I think you get a "yes, that's interesting"<br> <TabAtkins> astearns: did you want anything more?<br> <lea> +1 to solving the problem, the use cases are common<br> <kbabbitt> +1 let's do this<br> <TabAtkins> +1 from me, i'll raise issues<br> <TabAtkins> ydaniv: demos are also shared in the slides<br> <TabAtkins> fantasai: do we want to continue just in the issue, or start putting it in a draft?<br> <TabAtkins> astearns: in the issue for now, it's still early. some point soon can move it to a draft<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10574#issuecomment-2378025135 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 22:11:16 UTC