- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 25 Oct 2018 12:33:56 +0000
- To: public-css-archive@w3.org
The Houdini Task Force just discussed `[web-animations-1] Generalized Time Values and Timelines`. <details><summary>The full IRC log of that discussion</summary> <emilio> topic: [web-animations-1] Generalized Time Values and Timelines<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/2493#issuecomment-422109535<br> <TabAtkins> majidvp: Early on we looked at things people needed for scroll, but we early knew we needed to solve the more general use-case of interactive animated effects.<br> <TabAtkins> majidvp: Mobile or touch-friendly interface, you see drag-and-drop, scaling/zooming/transforming etc.<br> <TabAtkins> majidvp: Touch-based interactions.<br> <TabAtkins> majidvp: Righ tnow only way to do this is with touch-event handlers on main thread and use rAF().<br> <TabAtkins> majidvp: These are not time-based animations, just input-driven.<br> <TabAtkins> majidvp: Scroll-linked animations are a subset of these.<br> <TabAtkins> majidvp: Scroll is easier; it's 1d mostly.<br> <TabAtkins> majidvp: So you can map it to time, easy. And can use with WebAnim.<br> <TabAtkins> majidvp: Touch and gestures are more complex: not single-dimenstional, and are stateful.<br> <TabAtkins> majidvp: Almost impossible to do this declaratively in a way that's expressive.<br> <TabAtkins> majidvp: This is why people use the manual scripting approach on the main thread.<br> <TabAtkins> majidvp: What we want to do is use AW to handle these use-cases as well.<br> <TabAtkins> majidvp: If we can pull this off, we can incentivize devs to move some critical UI rendering work off of main thread.<br> <TabAtkins> majidvp: It also lets browsers know it's an input-drive animation, so they can prioritize properly.<br> <TabAtkins> majidvp: We've all seen janky touch-based effects; it's very hard to pull off on the web.<br> <TabAtkins> majidvp: So if AW can handle these, it should help a lot with the responsiveness.<br> <TabAtkins> majidvp: And will have the same basic play/pause api we have for regular time-based animations.<br> <TabAtkins> majidvp: So a lot of goodness here.<br> <TabAtkins> majidvp: This is basically what we're going for scroll, but supercharged.<br> <TabAtkins> majidvp: Like to start with pointer inputs, you can do a lot of interesting things there.<br> <TabAtkins> majidvp: So why AW as a primitive?<br> <TabAtkins> majidvp: First it already runs off-main-thread. Designed so it can be stateful.<br> <TabAtkins> majidvp: And because it's JS you can express complex things that would be very hard to do declaratively.<br> <TabAtkins> majidvp: Main thing missing is having input other than scroll.<br> <TabAtkins> majidvp: We've been thinking about this for a little while. Initially thought we could fit everything into timelines; maybe multiple timelines for animations.<br> <TabAtkins> majidvp: I chatted with Brian and Antoine last time, and realized model doesn't work well. Multi-timeline doesn't fit well with animations, too complex.<br> <TabAtkins> majidvp: I think our new appraoch is reasonable.<br> <TabAtkins> majidvp: AniamtionInput is separate from AnimationTimeline<br> <TabAtkins> majidvp: But touch animations can have multiple effects: pointer-input, scroll-input, etc.<br> <TabAtkins> majidvp: More complex scroll too - 2d scrolling, maybe active scroll or momentum. Maybe know that finger is down, even if not actively moving.<br> <TabAtkins> majidvp: So this keeps timeline simple, focused on that use-case, and then have the wider thing.<br> <TabAtkins> majidvp: I want to build this model so later if there's a gesture exposed, maybe we can get access to those.<br> <TabAtkins> majidvp: Also want to make sure that you can listen/unlisten to a given input.<br> <TabAtkins> majidvp: Passively monitor something without it actually ticking you.<br> <TabAtkins> majidvp: Conceptual diagram:<br> <TabAtkins> majidvp: [on screen]<br> <TabAtkins> majidvp: This is the high-level IDL: [on screen]<br> <TabAtkins> majidvp: Example of PointerAnimationInput [on screen]<br> <TabAtkins> majidvp: Proposal has a lot more details.<br> <TabAtkins> majidvp: Here's an example of a more sophisticated scroll...<br> <TabAtkins> majidvp: I like to dream, here's how a gesture might look.<br> <TabAtkins> majidvp: [example code]<br> <TabAtkins> majidvp: [example of mixing scroll+time]<br> <TabAtkins> majidvp: Hidey-bar, for some portion you want to be linked to scroll, when user lifts their ifnger you want to complete animation based on time.<br> <TabAtkins> majidvp: Set up two inputs...<br> <TabAtkins> majidvp: Set actual timeline to empty, then provide the two inputs explicitly.<br> <TabAtkins> majidvp: This misses its timeline, even tho it takes a scroll as an input, so we can control precisely when scrolling will tick the animation. If provided as a timeline input, it would always tick no matter what.<br> <TabAtkins> majidvp: So this is a high-level example, showing general direction.<br> <TabAtkins> majidvp: So you might ask why not just use events?<br> <TabAtkins> majidvp: For one, bubbling happens. We don't want to necessarily expose DOM via bubbling.<br> <TabAtkins> majidvp: For two, pull vs push. We think pulling makes more sense.<br> <TabAtkins> majidvp: One possiblity - instead of this value concept, maybe have a list of events that occurred since last frame.<br> <TabAtkins> majidvp: Maybe use event interface without actually inheriting from EventListener.<br> <TabAtkins> Rossen: So what are next steps?<br> <TabAtkins> Rossen: Continue in WICG?<br> <TabAtkins> majidvp: No, it's in Houdini already, we'll continue to work there.<br> <TabAtkins> majidvp: I'm working with Brian now.<br> <TabAtkins> majidvp: SCrollTimeline, WA, and AW have interdependencies.<br> <TabAtkins> majidvp: Last time Simon told me to make the extension point clear in WA spec. We're currently patching WA.<br> <TabAtkins> majidvp: So working with Brian, joined their monthly sync, to bring these concepts to that event.<br> <TabAtkins> majidvp: Try to make progress on defining theswe.<br> <TabAtkins> majidvp: And having this patchwork be propertly introduced and integrated into WA.<br> <TabAtkins> majidvp: Also hoping that ScrollTimeline will push forward at same time.<br> <TabAtkins> majidvp: And hoping to get dev feedback on ergonomics.<br> <TabAtkins> majidvp: That's on spec side.<br> <TabAtkins> majidvp: For new things, I want to figure out this proposal.<br> <TabAtkins> majidvp: I think there's a lot of value.<br> <TabAtkins> majidvp: For moving interactive content off of main thread.<br> <TabAtkins> majidvp: I think our experiment with getting scroll to work from animationworklet has been informative.<br> <TabAtkins> majidvp: Want to push it so we're in good place.<br> <TabAtkins> majidvp: One last thing - people are thinking about introducing some form of input to Workers, so I'm gonna try to see if there's a general solution here for all these use-cases.<br> <TabAtkins> majidvp: I'll try to implement in the polyfill first.<br> <TabAtkins> majidvp: You can do all this with PointerEvents today.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2493#issuecomment-433032702 using your GitHub account
Received on Thursday, 25 October 2018 12:33:58 UTC