22:39:31 RRSAgent has joined #fx 22:39:31 logging to http://www.w3.org/2016/02/02-fx-irc 22:39:36 RRSAgent, make logs public 22:39:50 dino has joined #fx 22:40:07 RRSAgent, this meeting spans midnight 22:42:54 hyojin has joined #fx 22:44:08 topic: Scroll-linked animations 22:44:13 https://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html 22:44:18 shane: 2 years ago TPAC dean presented nice demo of scroll-linked animation effects, with email to back it up 22:44:43 shane: it seems like there's some interest in look into that further 22:44:47 birtles: yes that's right 22:44:52 shane: there's interest from us as well 22:45:04 ... it seems like we should revisit that spec 22:45:14 dino: let's not get too hung up on the spec in that email 22:45:18 ... the syntax isn't that important 22:45:39 ... what's important is that, given that it's 1.5years ago, think about, "what's happened since?" 22:45:50 ... an increase in a sites that use scroll-linked effects 22:46:05 ... on the other hand, we have Houdini which is trying to define a very low-level way of overriding and having complete customization 22:46:31 ... I suggest our goal is to think, "is there a subset of stuff that we can agree upon to address the common use cases?" 22:46:41 ... in Web Animations and which is compatible with Houdini 22:46:52 ... and I think parallax, which is just one example 22:47:04 ... and another is animations, starting or stopping based on the position you hit in a page 22:47:23 ... there are other options like having animations that only trigger once, or every time, or only in one direction 22:47:40 ... if we address these common cases, but not the really complex ones like pull-to-refresh 22:47:49 ... it seems simple but is actually quick complex 22:47:59 shane: so do you think pull-to-refresh is out of scope? 22:48:09 dino: I think we could support part of if 22:48:26 ... I think our goal should be to make it faster that what you can currently do with javascript 22:48:36 ... i.e. the bits as browser vendors we can accelerate in some manner 22:48:45 jihye has joined #fx 22:49:04 shane: to the extent that these bits are useful for the complex cases like to pull-to-refresh smooth, natural, fast 22:49:15 ... even if some parts of it are running on the main thread 22:49:29 ... e.g. having animations that run to completion running on the compositor 22:49:38 ... and parts that stick to your finger 22:49:56 ... but run transitions between different types of behavior on the main thread 22:50:21 ... and later Houdini can fill the gaps or we can introduce some declarative syntax for it 22:50:39 dino: the email I sent does seem to work pretty well for parallax effects 22:51:03 ... and really it comes down to (1) when an animation starts/stops based on scroll, (2) using scroll as input to the animation instead of time 22:51:24 ... it got tricky when you have to choose scroll context: container or page 22:51:53 ... I was a bit scared that the syntax would get complicated when you have animations that only work in certain cases (e.g. only fire once) or when running on iframes 22:52:26 shane: would it be fair to capture the simple things in CSS to keep things simple and cover 80% and accept that you have to fall back on Web Animations for the complex cases 22:52:30 dino: I agree with that 22:52:51 shane: something that I should bring up, Ian Vollick was concerned about not considering the most complex use cases 22:53:03 ... before we implement, I think we want to experiment to make sure this does get us on the right path 22:53:12 dino: the right path to what? 22:53:20 shane: to support more complex things like pull-to-refresh 22:53:39 dino: while pull-to-refresh might not be what we want to do, the primitives should still be useful for that 22:53:53 Rossen: we looked at this post-TPAC and there has definitely been internal interest 22:54:01 ... the things you guys say resonates with me 22:54:16 ... however, we shouldn't kill the great in pursuit of the perfect 22:54:24 ... and we should admit that the perfect might not come 22:54:35 ... people will keep inventing new patterns 22:54:53 ... there are things like position observer and all kinds of other triggers that are starting to become more readily available for content creators 22:55:33 ... and I'm curious, besides basically being able to express the timeline as scroll-position, was there anything else that was actually needed to be able to build all these things? 22:55:36 dino: no 22:56:10 Rossen: when you were experimenting, the one things that appears difficult is scroll position are fairly dynamic... time could be changing in terms of measure underneath you 22:56:33 ... if you scroll somewhere and there are all kinds of layout updates, your 'time' becomes very unstable 22:56:42 dino: that was part of roc's feedback 22:57:05 ... he liked the idea but was concerned about the animation affecting the animation (by affecting layout) 22:57:20 ... I pointed out that transitions already have this problem with hover 22:57:37 ... you can have animation that changes layout which causes the scroll trigger to not have fired etc. 22:57:41 ... that bit is very worrying 22:57:56 shane: because we did that with transitions, it may be simply to late to fix this problem 22:58:36 ... we can think about a model where a triggered transition completes, and then reverses 22:58:45 dino: that's not so different from just doing it immediately 22:59:12 zcorpan: do we actually need to fix that in transitions 22:59:22 shane: a lot of people have pointed it out that its a problem with the transitions model 22:59:33 dbaron: what sorts of cases are you worried about with this? 23:00:04 ... some examples of scroll-linked animation is where there is content that changes while you scroll down, and even if that container resizes... 23:00:42 ... I guess, is part of the problem that changes are linked to scroll position that might not be consistent in terms of content that is animated? 23:01:55 zcorpan: if you have a parallax, and the animated content overflows and the scroll extent changes, then the animation time would change 23:02:20 dbaron: it wouldn't happen if you used 3d transforms, since the scroll extent wouldn't change... 23:02:39 dino: but people want pixel perfection 23:03:25 ... using perspective to do parallax is tricky for a designer 23:03:55 ... if they have a 100-high viewport, whole of the page, 200px image... if they want to do it with perspective they have to do a lot of math 23:04:08 dbaron: is there a way we can make the scroll extent right? 23:05:21 shane: can fix the timeline to the pre-animation scroll, so if animations change the scroll size then the timeline gets longer but the values stay stable. 23:05:56 dbaron: I think there's a variant of that that's ok, e.g. tie the timeline to the scroll extent when scrolled to the top 23:06:08 ... but I don't think that works when the window is resized 23:06:22 Rossen: in the start state of the animation, you have a timeline that is expressed in terms of the scroll distance that you have 23:06:47 ... then you can say that the scroll speed becomes fixed 23:06:54 ... so say that initial scroll distance is n 23:07:23 ... if n becomes 2n, then you say we don't care, since the animation speed is a fixed ratio of n 23:07:28 ... (i.e. timeline speed) 23:08:02 ... the other way is to make it relative so that if the scroll size changes (e.g. infinite scroll case), that relative measure over n also changes 23:08:32 ... in either case I think we can come to a stable state 23:08:53 dbaron: one thing I'm worried about is having animations that are tied to exact sizes 23:09:09 ... what I'm wondering is, is there a way to define these animations in pieces? 23:09:36 ... so you say, "I have this thing in the middle of the scrollable area and I want to define how just this piece moves within its scrollable container" 23:09:52 ... without defining it as a master thing as a position of the scrollable container 23:10:04 dino: I think my original proposal has that 23:10:42 ... you're scrolling down the page, when you hit a point, you have a negative translate that applies after a trigger point is hit and finishes when another trigger point is hit 23:10:52 ... and the animation is just a percentage of that distance 23:11:00 dbaron: how do you define those trigger points? 23:11:16 dino: in the demo, it uses abs pos, but you could do it as a percentage of an element 23:11:46 ... or percentage of the viewport 23:11:55 ... basically you want it to run when the element comes into view 23:12:10 s/of the viewport/of the visible viewport/ 23:12:28 Rossen: how do you fix the reentrancy problem? 23:12:44 ... if the element that you're animating changes the size of the scrollable container... 23:13:08 dbaron: can the triggers just be pre-transform? 23:13:12 dino: yeah, that was the idea 23:13:16 ... maybe you need to choose that 23:13:38 ... if you define your triggers to be relative to the viewport then it doesn't really matter if something changes the height 23:14:21 shane: I think you want to establish anchor points that are fixed independent of the scroll position 23:15:22 ... the anchor points are points of reference between a scroll axis and a time axis, i.e. seconds to px 23:16:09 dino: so we're solving the parallax problem at the same time here but there are other cases where you simply want to trigger a time-based animation based on scroll-position 23:17:08 Rossen: you don't need an anchor point in that case 23:17:33 shane: the animation is still anchored in that it comes into effect at a certain point but its progression is not tied to scroll position 23:19:56 dino: for the simple case, of fire-once animations, we need a trigger and some way of specifying that 23:20:28 birtles: 3 levels: (1) fire once (2) fire multiple times (3) tying to scroll progression 23:21:29 dino: the third part of the email was additive animations 23:22:57 shane: for circular references, prefer variables pattern of bulk invalidating rather than SMIL algorithm 23:25:37 [discussion about avoiding scroll container size change] 23:27:09 shane: want to avoid more things that force scrolling back to the main thread 23:28:40 dbaron: I think if you want that, the restrictions would mean wanting a spec that's limited to parallax rather than general scroll-linked animations 23:31:23 dino: I think people will discover how to use this performantly, even though using it generally has perf issues. 23:31:29 shane: I can live with that; similar to custom layout. 23:31:47 zcorpan: we can communicate what's fast 23:31:52 dino: so can developer tools 23:32:44 dino has joined #fx 23:32:56 shane: can some animations run a little bit out of sync so that scrolling stays on compositor? 23:33:01 dino: e.g., changing background color? 23:33:25 dino: changing colors with scroll is probably subtle-enough and people won't notice being out of sync 23:33:34 birtles: except step timing functions 23:33:57 shane: but what if you explicitly ask for an async timebase 23:34:40 dino: devtool could show which animations linked to scroll run on compositor 23:34:52 dino: if you animate a transform and a background-color, we have to make sure they start/finish at the same time 23:35:21 dino: e.g., if you animate left and translate at the same time, we don't necesasrily animate left at 60fps even though we do for the transform 23:35:59 birtles: We (Gecko) don't run transform on the compositor for certain other animations on the same element, but no ties for different elements -- maybe animations groups in future 23:36:28 shane: biggest issue is animations being retriggered that could potentially form a loop, and parallax effects causing animatios to wobble like transition+:hover 23:36:48 tantek has joined #fx 23:36:49 dino: parallax wobbling people will understand; people understand wobbling in transitions 23:36:51 shepazu has joined #fx 23:37:39 shane: is demo JS or native code? 23:37:41 dino: native code 23:38:15 dino: one use case we haven't talked about was scroll effects like what Jihye showed scrolling into round display, scaling up and down as scrolled into/out of round display 23:38:23 Rossen: aligns with this model 23:39:01 zcorpan: probably don't want linear scaling 23:39:20 dino: we haven't talked about timing functions, which could get close enough for that effect 23:39:54 shane: I have a list of scroll customization use cases, maybe worth going through them. 23:40:51 zcorpan has joined #fx 23:41:47 Rossen: was demo yesterday JS or Android code? 23:41:51 Hyojin: JS 23:44:31 dino: one reason I implemented it natively was to show it could improve scrolling on the iPad, where slow scrolling path is noticeable (big screen, touch, low power) 23:44:43 shane: that being a successful experiment was a good sign 23:45:51 shane presents https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md 23:50:48 [looking it Hidey Bars] 23:51:29 shane: I don't want to use these cases to stop us moving forward on parallax; just want to look over these to see if there are simple things we can add to the spec that would make these a lot easier 23:52:05 shane: hidey bars and pull to refresh have implicit state machine that needs to be run on main thread in JS, and cost of having that means you need to bounce between main thread and compositor thread when deciding to establish new set of animations 23:52:32 shane: compositor parallax and compositor triggered animations reduces jank points for these, but doesn't eliminate jank 23:52:58 [rubber banding] 23:53:57 dino: could probably be approximated, but really, given amount of scroll as input, you're modifying how much viewport. It's an effect on scroll. 23:54:02 shane: can scroll be an animation target? 23:55:00 dino: point 3 (animate back) and point 4 (momentum deceleration) are hard 23:56:39 dino: keep rubber banding as maybe, await polyfills? 23:56:50 Rossen: skip snap points; already have declarative way 23:57:46 Ojan: extensibility point -- you might disagree with decisions CSS WG made and want to do things differently 23:58:17 shane: snap points require animating scroll -- can't now -- but would like to 23:59:09 shane: so dead end until then 23:59:42 [pull to refresh] 23:59:42 ojan: rubber band plus 00:00:00 shane: on some impls flicking can cause pull to refresh 00:00:23 ojan: at least seeing the thing, maybe not commit 00:01:13 dino: in most cases as pull-to-refresh, there is an animation based on scroll position 00:01:19 shane: but this is scroll position going negative 00:03:55 ojan: more complicated state machine than hidey bars 00:04:02 shane: but still fundamentally a state machine 00:04:19 shane: I think we handle custom scrollers completely 00:04:30 [custom scrollers] (move this 1 line up) 00:09:17 [retargeting scrolling] 00:09:33 dino: might be easy declarative solution to this but not about animations 00:09:41 shane: but web animations need to be able to do scroll animations 00:09:44 [disable scroll chaining] 00:09:51 shane: outside of scope of parallax api 00:10:15 [custom scroll limit] 00:11:07 [custom overscroll] 00:11:48 Florian has joined #fx 00:12:03 topic: next steps 00:12:13 shane: need something that's more than dean's email, maybe an explainer doc derived from it 00:12:22 dino: not at all tied to what I wrote 00:12:32 shane: dino, want to start with that and we can then bikeshed on the syntax 00:13:04 ACTION dino to turn email into an explainer doc 00:13:04 Created ACTION-92 - Turn email into an explainer doc [on Dean Jackson - due 2016-02-10]. 00:13:22 shane: others can help turn it into a spec once that happens 00:14:24 shane: want help with web animations api...? 00:14:45 dino: important to have web animations equivalent and ultimately (when houdini specs exist) defined in terms of JS that you could implement in a scrolling worker 00:15:11 I actually tried to work out the web animations api a long time ago but got stuck, probably because I thought scroll timelines would be re-used (https://wiki.mozilla.org/Platform/Layout/Extended_Timelines) 00:15:28 Rossen: going back... scroll limit used for being able to create infinite scrolls. Mostly for list view controls. Where you control amount of content that you have, and as you're building ahead, want to constrain scrolling to some position so you don't scroll to content that's not ready yet 00:17:19 for animation-behavior, from Dean's proposal, we have something similar in CSS Animations 2 now: https://drafts.csswg.org/css-animations-2/#animation-composition 00:19:21 shane: dino, want help with web animations api? 00:19:30 dino: yes but not yet. Won't get to it until at least next week. 00:20:16 when I tried to map Dean's proposal (or something similar) to Web Animations I ran into trouble because I was trying to re-use ScrollTimeline objects 00:20:31 it got messy trying to use an Animation's playbackRate to map seconds to scroll timeline's units 00:20:42 but I think if you create a new ScrollTimeline for each application you can probably avoid that 00:21:04 (also, I want to rename animation-timebase to animation-timeline) 00:34:19 stakagi has joined #fx 00:47:18 dino has joined #fx 02:02:42 tantek has joined #fx 02:22:33 zcorpan has joined #fx 02:34:33 stakagi has joined #fx 02:38:54 zcorpan has joined #fx 02:46:36 Florian has joined #fx 02:56:58 tantek has joined #fx 03:01:35 Florian has joined #fx 03:19:42 zcorpan_ has joined #fx 03:46:05 stakagi has joined #fx 04:28:17 Florian has joined #fx 04:31:22 stakagi has joined #fx 04:31:45 Florian has joined #fx 05:01:23 Florian has joined #fx 05:43:44 Florian has joined #fx 05:50:55 tantek has joined #fx 05:53:49 Florian has joined #fx 06:10:28 tantek has joined #fx 06:25:30 shepazu has joined #fx 06:55:10 Tav has joined #fx 07:06:26 Florian has joined #fx 07:18:22 Tav has joined #fx 07:53:37 tantek has joined #fx 08:37:23 zcorpan has joined #fx 09:32:13 shepazu has joined #fx 09:33:31 tantek has joined #fx 09:51:46 zcorpan has joined #fx 09:53:21 dino has joined #fx 10:04:05 dino_ has joined #fx 10:08:40 Tav has joined #fx 10:11:22 tantek has joined #fx 11:52:01 Tav has joined #fx 13:21:09 Florian has joined #fx 13:47:16 tantek has joined #fx