IRC log of fx on 2016-02-02

Timestamps are in UTC.

22:39:31 [RRSAgent]
RRSAgent has joined #fx
22:39:31 [RRSAgent]
logging to http://www.w3.org/2016/02/02-fx-irc
22:39:36 [dbaron]
RRSAgent, make logs public
22:39:50 [dino]
dino has joined #fx
22:40:07 [dbaron]
RRSAgent, this meeting spans midnight
22:42:54 [hyojin]
hyojin has joined #fx
22:44:08 [birtles]
topic: Scroll-linked animations
22:44:13 [birtles]
https://lists.w3.org/Archives/Public/www-style/2014Sep/0135.html
22:44:18 [dbaron]
shane: 2 years ago TPAC dean presented nice demo of scroll-linked animation effects, with email to back it up
22:44:43 [birtles]
shane: it seems like there's some interest in look into that further
22:44:47 [birtles]
birtles: yes that's right
22:44:52 [birtles]
shane: there's interest from us as well
22:45:04 [birtles]
... it seems like we should revisit that spec
22:45:14 [birtles]
dino: let's not get too hung up on the spec in that email
22:45:18 [birtles]
... the syntax isn't that important
22:45:39 [birtles]
... what's important is that, given that it's 1.5years ago, think about, "what's happened since?"
22:45:50 [birtles]
... an increase in a sites that use scroll-linked effects
22:46:05 [birtles]
... 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 [birtles]
... 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 [birtles]
... in Web Animations and which is compatible with Houdini
22:46:52 [birtles]
... and I think parallax, which is just one example
22:47:04 [birtles]
... and another is animations, starting or stopping based on the position you hit in a page
22:47:23 [birtles]
... there are other options like having animations that only trigger once, or every time, or only in one direction
22:47:40 [birtles]
... if we address these common cases, but not the really complex ones like pull-to-refresh
22:47:49 [birtles]
... it seems simple but is actually quick complex
22:47:59 [birtles]
shane: so do you think pull-to-refresh is out of scope?
22:48:09 [birtles]
dino: I think we could support part of if
22:48:26 [birtles]
... I think our goal should be to make it faster that what you can currently do with javascript
22:48:36 [birtles]
... i.e. the bits as browser vendors we can accelerate in some manner
22:48:45 [jihye]
jihye has joined #fx
22:49:04 [birtles]
shane: to the extent that these bits are useful for the complex cases like to pull-to-refresh smooth, natural, fast
22:49:15 [birtles]
... even if some parts of it are running on the main thread
22:49:29 [birtles]
... e.g. having animations that run to completion running on the compositor
22:49:38 [birtles]
... and parts that stick to your finger
22:49:56 [birtles]
... but run transitions between different types of behavior on the main thread
22:50:21 [birtles]
... and later Houdini can fill the gaps or we can introduce some declarative syntax for it
22:50:39 [birtles]
dino: the email I sent does seem to work pretty well for parallax effects
22:51:03 [birtles]
... 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 [birtles]
... it got tricky when you have to choose scroll context: container or page
22:51:53 [birtles]
... 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 [birtles]
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 [birtles]
dino: I agree with that
22:52:51 [birtles]
shane: something that I should bring up, Ian Vollick was concerned about not considering the most complex use cases
22:53:03 [birtles]
... before we implement, I think we want to experiment to make sure this does get us on the right path
22:53:12 [birtles]
dino: the right path to what?
22:53:20 [birtles]
shane: to support more complex things like pull-to-refresh
22:53:39 [birtles]
dino: while pull-to-refresh might not be what we want to do, the primitives should still be useful for that
22:53:53 [birtles]
Rossen: we looked at this post-TPAC and there has definitely been internal interest
22:54:01 [birtles]
... the things you guys say resonates with me
22:54:16 [birtles]
... however, we shouldn't kill the great in pursuit of the perfect
22:54:24 [birtles]
... and we should admit that the perfect might not come
22:54:35 [birtles]
... people will keep inventing new patterns
22:54:53 [birtles]
... 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 [birtles]
... 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 [birtles]
dino: no
22:56:10 [birtles]
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 [birtles]
... if you scroll somewhere and there are all kinds of layout updates, your 'time' becomes very unstable
22:56:42 [birtles]
dino: that was part of roc's feedback
22:57:05 [birtles]
... he liked the idea but was concerned about the animation affecting the animation (by affecting layout)
22:57:20 [birtles]
... I pointed out that transitions already have this problem with hover
22:57:37 [birtles]
... you can have animation that changes layout which causes the scroll trigger to not have fired etc.
22:57:41 [birtles]
... that bit is very worrying
22:57:56 [birtles]
shane: because we did that with transitions, it may be simply to late to fix this problem
22:58:36 [birtles]
... we can think about a model where a triggered transition completes, and then reverses
22:58:45 [birtles]
dino: that's not so different from just doing it immediately
22:59:12 [birtles]
zcorpan: do we actually need to fix that in transitions
22:59:22 [birtles]
shane: a lot of people have pointed it out that its a problem with the transitions model
22:59:33 [birtles]
dbaron: what sorts of cases are you worried about with this?
23:00:04 [birtles]
... 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 [birtles]
... 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 [birtles]
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 [birtles]
dbaron: it wouldn't happen if you used 3d transforms, since the scroll extent wouldn't change...
23:02:39 [birtles]
dino: but people want pixel perfection
23:03:25 [birtles]
... using perspective to do parallax is tricky for a designer
23:03:55 [birtles]
... 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 [birtles]
dbaron: is there a way we can make the scroll extent right?
23:05:21 [shane]
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 [birtles]
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 [birtles]
... but I don't think that works when the window is resized
23:06:22 [birtles]
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 [birtles]
... then you can say that the scroll speed becomes fixed
23:06:54 [birtles]
... so say that initial scroll distance is n
23:07:23 [birtles]
... if n becomes 2n, then you say we don't care, since the animation speed is a fixed ratio of n
23:07:28 [birtles]
... (i.e. timeline speed)
23:08:02 [birtles]
... 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 [birtles]
... in either case I think we can come to a stable state
23:08:53 [birtles]
dbaron: one thing I'm worried about is having animations that are tied to exact sizes
23:09:09 [birtles]
... what I'm wondering is, is there a way to define these animations in pieces?
23:09:36 [birtles]
... 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 [birtles]
... without defining it as a master thing as a position of the scrollable container
23:10:04 [birtles]
dino: I think my original proposal has that
23:10:42 [birtles]
... 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 [birtles]
... and the animation is just a percentage of that distance
23:11:00 [birtles]
dbaron: how do you define those trigger points?
23:11:16 [birtles]
dino: in the demo, it uses abs pos, but you could do it as a percentage of an element
23:11:46 [birtles]
... or percentage of the viewport
23:11:55 [birtles]
... basically you want it to run when the element comes into view
23:12:10 [birtles]
s/of the viewport/of the visible viewport/
23:12:28 [birtles]
Rossen: how do you fix the reentrancy problem?
23:12:44 [birtles]
... if the element that you're animating changes the size of the scrollable container...
23:13:08 [birtles]
dbaron: can the triggers just be pre-transform?
23:13:12 [birtles]
dino: yeah, that was the idea
23:13:16 [birtles]
... maybe you need to choose that
23:13:38 [birtles]
... 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 [birtles]
shane: I think you want to establish anchor points that are fixed independent of the scroll position
23:15:22 [birtles]
... the anchor points are points of reference between a scroll axis and a time axis, i.e. seconds to px
23:16:09 [birtles]
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 [birtles]
Rossen: you don't need an anchor point in that case
23:17:33 [birtles]
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 [birtles]
dino: for the simple case, of fire-once animations, we need a trigger and some way of specifying that
23:20:28 [dbaron]
birtles: 3 levels: (1) fire once (2) fire multiple times (3) tying to scroll progression
23:21:29 [birtles]
dino: the third part of the email was additive animations
23:22:57 [dbaron]
shane: for circular references, prefer variables pattern of bulk invalidating rather than SMIL algorithm
23:25:37 [dbaron]
[discussion about avoiding scroll container size change]
23:27:09 [dbaron]
shane: want to avoid more things that force scrolling back to the main thread
23:28:40 [dbaron]
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 [dbaron]
dino: I think people will discover how to use this performantly, even though using it generally has perf issues.
23:31:29 [dbaron]
shane: I can live with that; similar to custom layout.
23:31:47 [dbaron]
zcorpan: we can communicate what's fast
23:31:52 [dbaron]
dino: so can developer tools
23:32:44 [dino]
dino has joined #fx
23:32:56 [dbaron]
shane: can some animations run a little bit out of sync so that scrolling stays on compositor?
23:33:01 [dbaron]
dino: e.g., changing background color?
23:33:25 [dbaron]
dino: changing colors with scroll is probably subtle-enough and people won't notice being out of sync
23:33:34 [dbaron]
birtles: except step timing functions
23:33:57 [dbaron]
shane: but what if you explicitly ask for an async timebase
23:34:40 [dbaron]
dino: devtool could show which animations linked to scroll run on compositor
23:34:52 [dbaron]
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 [dbaron]
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 [dbaron]
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 [dbaron]
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]
tantek has joined #fx
23:36:49 [dbaron]
dino: parallax wobbling people will understand; people understand wobbling in transitions
23:36:51 [shepazu]
shepazu has joined #fx
23:37:39 [dbaron]
shane: is demo JS or native code?
23:37:41 [dbaron]
dino: native code
23:38:15 [dbaron]
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 [dbaron]
Rossen: aligns with this model
23:39:01 [dbaron]
zcorpan: probably don't want linear scaling
23:39:20 [dbaron]
dino: we haven't talked about timing functions, which could get close enough for that effect
23:39:54 [dbaron]
shane: I have a list of scroll customization use cases, maybe worth going through them.
23:40:51 [zcorpan]
zcorpan has joined #fx
23:41:47 [dbaron]
Rossen: was demo yesterday JS or Android code?
23:41:51 [dbaron]
Hyojin: JS
23:44:31 [dbaron]
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 [dbaron]
shane: that being a successful experiment was a good sign
23:45:51 [dbaron]
shane presents https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/UseCases.md
23:50:48 [dbaron]
[looking it Hidey Bars]
23:51:29 [dbaron]
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 [dbaron]
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 [dbaron]
shane: compositor parallax and compositor triggered animations reduces jank points for these, but doesn't eliminate jank
23:52:58 [dbaron]
[rubber banding]
23:53:57 [dbaron]
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 [dbaron]
shane: can scroll be an animation target?
23:55:00 [dbaron]
dino: point 3 (animate back) and point 4 (momentum deceleration) are hard
23:56:39 [dbaron]
dino: keep rubber banding as maybe, await polyfills?
23:56:50 [dbaron]
Rossen: skip snap points; already have declarative way
23:57:46 [dbaron]
Ojan: extensibility point -- you might disagree with decisions CSS WG made and want to do things differently
23:58:17 [dbaron]
shane: snap points require animating scroll -- can't now -- but would like to
23:59:09 [dbaron]
shane: so dead end until then
23:59:42 [dbaron]
[pull to refresh]
23:59:42 [dbaron]
ojan: rubber band plus
00:00:00 [dbaron]
shane: on some impls flicking can cause pull to refresh
00:00:23 [dbaron]
ojan: at least seeing the thing, maybe not commit
00:01:13 [dbaron]
dino: in most cases as pull-to-refresh, there is an animation based on scroll position
00:01:19 [dbaron]
shane: but this is scroll position going negative
00:03:55 [dbaron]
ojan: more complicated state machine than hidey bars
00:04:02 [dbaron]
shane: but still fundamentally a state machine
00:04:19 [dbaron]
shane: I think we handle custom scrollers completely
00:04:30 [dbaron]
[custom scrollers] (move this 1 line up)
00:09:17 [dbaron]
[retargeting scrolling]
00:09:33 [dbaron]
dino: might be easy declarative solution to this but not about animations
00:09:41 [dbaron]
shane: but web animations need to be able to do scroll animations
00:09:44 [dbaron]
[disable scroll chaining]
00:09:51 [dbaron]
shane: outside of scope of parallax api
00:10:15 [dbaron]
[custom scroll limit]
00:11:07 [dbaron]
[custom overscroll]
00:11:48 [Florian]
Florian has joined #fx
00:12:03 [dbaron]
topic: next steps
00:12:13 [dbaron]
shane: need something that's more than dean's email, maybe an explainer doc derived from it
00:12:22 [dbaron]
dino: not at all tied to what I wrote
00:12:32 [dbaron]
shane: dino, want to start with that and we can then bikeshed on the syntax
00:13:04 [dbaron]
ACTION dino to turn email into an explainer doc
00:13:04 [trackbot]
Created ACTION-92 - Turn email into an explainer doc [on Dean Jackson - due 2016-02-10].
00:13:22 [dbaron]
shane: others can help turn it into a spec once that happens
00:14:24 [dbaron]
shane: want help with web animations api...?
00:14:45 [dbaron]
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 [birtles]
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 [dbaron]
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 [birtles]
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 [dbaron]
shane: dino, want help with web animations api?
00:19:30 [dbaron]
dino: yes but not yet. Won't get to it until at least next week.
00:20:16 [birtles]
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 [birtles]
it got messy trying to use an Animation's playbackRate to map seconds to scroll timeline's units
00:20:42 [birtles]
but I think if you create a new ScrollTimeline for each application you can probably avoid that
00:21:04 [birtles]
(also, I want to rename animation-timebase to animation-timeline)
00:34:19 [stakagi]
stakagi has joined #fx
00:47:18 [dino]
dino has joined #fx
02:02:42 [tantek]
tantek has joined #fx
02:22:33 [zcorpan]
zcorpan has joined #fx
02:34:33 [stakagi]
stakagi has joined #fx
02:38:54 [zcorpan]
zcorpan has joined #fx
02:46:36 [Florian]
Florian has joined #fx
02:56:58 [tantek]
tantek has joined #fx
03:01:35 [Florian]
Florian has joined #fx
03:19:42 [zcorpan_]
zcorpan_ has joined #fx
03:46:05 [stakagi]
stakagi has joined #fx
04:28:17 [Florian]
Florian has joined #fx
04:31:22 [stakagi]
stakagi has joined #fx
04:31:45 [Florian]
Florian has joined #fx
05:01:23 [Florian]
Florian has joined #fx
05:43:44 [Florian]
Florian has joined #fx
05:50:55 [tantek]
tantek has joined #fx
05:53:49 [Florian]
Florian has joined #fx
06:10:28 [tantek]
tantek has joined #fx
06:25:30 [shepazu]
shepazu has joined #fx
06:55:10 [Tav]
Tav has joined #fx
07:06:26 [Florian]
Florian has joined #fx
07:18:22 [Tav]
Tav has joined #fx
07:53:37 [tantek]
tantek has joined #fx
08:37:23 [zcorpan]
zcorpan has joined #fx
09:32:13 [shepazu]
shepazu has joined #fx
09:33:31 [tantek]
tantek has joined #fx
09:51:46 [zcorpan]
zcorpan has joined #fx
09:53:21 [dino]
dino has joined #fx
10:04:05 [dino_]
dino_ has joined #fx
10:08:40 [Tav]
Tav has joined #fx
10:11:22 [tantek]
tantek has joined #fx
11:52:01 [Tav]
Tav has joined #fx
13:21:09 [Florian]
Florian has joined #fx
13:47:16 [tantek]
tantek has joined #fx