11:40:08 RRSAgent has joined #fx 11:40:08 logging to https://www.w3.org/2018/04/11-fx-irc 11:40:10 RRSAgent, make logs world 11:40:10 Zakim has joined #fx 11:40:12 Meeting: CSS-SVG Task Force Teleconference 11:40:12 Date: 11 April 2018 11:40:22 ericwilligers has joined #fx 11:40:35 https://docs.google.com/document/d/1j3oeLpgX6kneG9lEgZQ80kitdyN-vbAYGPiwtYyN3tw/edit# 11:42:37 present+ 11:42:42 present+ 11:42:58 birtles: we're implementing webanimations in gecko, blink and webkit at the moment, one goal is to ship getAnimations which lets you look at CSS animations and transitions from javascript 11:43:13 present+ 11:43:23 birtles: there's a few things we need to address, mapping between css animations and web animations 11:43:34 birtles: another is pseudoelements and how to represent them 11:43:54 birtles: we were expecting a ?? api on the web platform by now but this hasn't happened yet 11:44:05 birtles: let's start with animationworklet 11:44:36 majidvp: animationworklet was previously similar to paintworklet, you would input style, and output style values directly 11:45:12 majidvp: this was a major objection because it was an animation but had a parallel world. The request was to make it fit better with the webanimation model 11:45:36 present+ 11:45:45 majidvp: The new model works very much like a custom animation. It allows you to customize what the animation does, where animations take the current time and apply a linear transformation to set the keyframe time 11:46:01 majidvp: we allow the authors to replace this with a function which inputs time and outputs time 11:46:27 majidvp: this allows you to do animations off thread, with state 11:46:45 present+ 11:46:50 majidvp: you can also have a scrolltimeline and other types of timelines, i.e. pointer timeline, gesture timeline, and do more interesting things inside the function imperatively 11:47:26 majidvp: in the future we'll also use the grouping mechanism from animations level 2 to do more interesting things that affect multiple elements with custom coordination between them 11:47:45 majidvp: we have a whole set of examples: scroll linked examples, examples with state, pull to refresh which coordinates handoff between timeline 11:48:00 majidvp: these can all be done without a lot of complexity inside AnimationWorklet. 11:48:48 majidvp: people have been asking for custom animations. One way AnimationWorklet is working in this direction is that you can do these things off of the main thread while preserving the ability to do custom effects. 11:49:26 Rossen: on monday you mentioned scroll triggers as well, besides time. Everything we've talked about up until now has been time based. How does scroll control time 11:49:58 majidvp: there's already a proposal to map scroll to become a timeline. Animations allow for an abstract time which doesn't have to be wall time, allowing you to map a scroll position to a time value which can also be fed to normal web animations keying off of scroll 11:50:20 majidvp: this can also feed into custom animations / animation worklet, allowing you to use scroll offset. 11:50:32 majidvp: there's the possibility to have richer timelines such a pointer timeline or touch timeline. 11:50:52 majidvp: I have a separate proposal to generalize the timeline proposal, the timeline currently is only a double 11:51:12 majidvp: so to map scroll directly you need two timelines, but if we allow flexibility in what constitutes a time then you could have a multi-pointer timeline 11:51:26 majidvp: these are all experimental. For scroll we have an easy way based on the scrolltimeline proposal 11:51:54 smfr: there's two ways of thinking about this, time could be progress or time could be time 11:52:08 he's graouts 11:52:34 graouts: there is a notion of progress in webanimations in the computed timing. progress is what computation of effects is based on - but the only properties that you're manipulating are time related 11:52:49 birtles: it says in the introduction that these time values normally represent time but maybe we shouldn't call it time 11:52:58 graouts: reality is that right now everything is time 11:53:10 birtles: but we really just want progress 11:53:23 birtles: progress is really a fraction between 0 and 1 and start times are outside of that range 11:53:36 birtles: we'd have to think about the term a bit 11:53:50 birtles: maybe it's worth rethinking but we've already shipped interfaces based on the naming 11:54:28 graouts: personally i think it's okay keeping something mostly time driven to express the API, but in my mind when we're thinking of additional inputs we should compartementalize these things as a phase which just uses these inputs to produce times 11:54:49 graouts: current time would be the local time for an animation 11:54:54 birtles: i think in level 2 that's exposed 11:55:19 graouts: looking at the animationworklet spec. I'm thinking about producing these values for a timeline in a more declarative way 11:55:42 graouts: for example, given a region, produce a progress through that. We'd like to avoid having to worry about layout values or having to resolve layout during scrolling 11:55:48 graouts: we might want something more abstract 11:55:54 surma: is that currently a possibility? 11:56:00 graouts: no, but i don't mean about animation particularly 11:56:40 majidvp: I agree, we have been implementing a scrolltimeline and have found a lot of issues, like knowing which offsets to specify in the scrolltimeline when the container changes sizes. Suddenly the duration you specify no longer matches 11:56:52 majidvp: we should go back and work this out to be more flexible 11:57:06 majidvp: it's very easy to do the wrong things with this 11:57:28 majidvp: normally animations when you call play record their start offset, but this doesn't make a lot of sense for scroll linked animations 11:57:56 majidvp: this notion of progress helps make things make more sense. The progress comes from the time or the scroll timeline 11:58:13 smfr: does a scroll linked animation behave like a scroll linked animation with a rate of 0 and you scrub through it 11:58:16 majidvp: yes 11:58:24 birtles: the playback rate is still 1, but it doesn't get any updates until you scroll 11:58:42 surma: playbackRate doesn't really make sense 11:59:01 smfr: if you want to multiply around the scroll rate you would do that programmatically? 11:59:06 birtles: you could use rate 11:59:26 smfr: another difference is the model that drives the animation. I.e. does a scroll linked animation tick at 60fps? 11:59:32 majidvp: yes, we think so, to avoid burning cycles 11:59:39 surma: should we spec this or is it just an optimization? 11:59:48 graouts: the api doesn't expose anything related to an actual tick 11:59:55 smfr: is it implicit that there's a 60fps clock? 12:00:04 surma: i think the intention is that we can do frame perfect effects 12:00:26 birtles: the current model is through the documenttimeline, which is from the html spec is a step where you update the timelines associated with the document 12:00:39 smfr: when does html spec update document? 12:00:53 smfr: i.e. doesn't tick regularly 12:01:19 birtles: it's just spec'd that the browser will update the rendering, so we need to spec when the scrolltimeline gets updated 12:01:49 smfr: feels to me that the cleaner way would be for webanimations specs to have some wording about when the animations need to update which feeds into the html5 event loop 12:02:03 birtles: i tried to do it that way but dominic requested the other way around, with a hook to call from webanimations 12:02:18 smfr: html5 spec already has problems around not specifying how requestAnimationFrame works 12:02:52 birtles: we could add something for scrolling or more generic 12:03:06 smfr: do worklets act as a node in a time graph, which then output just a new time? 12:03:28 majidvp: yes, that's what makes it fit nicely with the model, it uses the normal flow of information in the webanimation graph 12:03:57 majidvp: our implementation is very simple, it's like composited animations, we take the current time of composited animations, send it to another thread which produces new localTime values which are fed into the keyframe to produce the output 12:04:03 smfr: this off the main thread is an implementation detail 12:04:06 everyone: agrees 12:04:14 ikilpatrick: we have to put one on the main thread as well 12:04:46 flackr: we want to use the same thread in our implementation, calling it from the main thread and block on the result to avoid worrying about state or global scopes 12:05:15 majidvp: you can use different strategies, can have a third thread which you call from both like we are planning, or this could be separate on the main thread 12:05:51 smfr: the existing webanimation spec allows users to poke transforms off the main thread 12:06:31 flackr: I dont' understand the concern because you can only look at your input times so you couldn't trigger an animation from that context 12:06:50 smfr: if the main thread is blocked, but your worklet is running and spits out new values will you see transforms change? 12:07:00 smfr: does the web animations spec require a main thread step before it can change transforms? 12:07:14 majidvp: it's similar to how we do composited animations right now, the compositor thread can be ahead 12:07:35 majidvp: you can query that state on the main thread, and it gives you what it thinks that state is based on its current notion of time which may be different from what's being shown to the user 12:07:58 majidvp: we'll have the same model. The animationworklet is working producing new values, and the value you have from animationworklet is stale from the last sync 12:08:09 surma: it has a snapshot of the most recent values 12:08:14 majidvp: similar to threaded scrolling 12:08:30 smfr: if there's more than one webanimation running, maybe one is on the main thread. do you still let the accelerated ones progress off the main thread 12:08:45 birtles: there's different heuristics for example if you're animating margin and transform with the same start time we do both on the main thread 12:09:06 birtles: can you run animationworklet both on the main thread and on the compositor in parallel? 12:09:20 flackr: you can actually run it synchronously 12:09:29 surma: the worklet concept allows that but the spec doesn't currently prescribe that 12:10:04 majidvp: technically you can run two copies, with different state 12:10:28 flackr: it doesn't have to be a copy, because the worklet runs on a parallel thread you can call it from the main thread and sycchronously wait for the result 12:11:01 majidvp: yes, you can have one thread where this is running and get main thread updates, or you could have a separate globalscope for use from the main thread to query 12:11:22 smfr: this gets back to the update model, how often does a worklet run? 12:11:41 majidvp: yes, and webanimation allows this. wall clock time is always changing but it's up to the implementation how often it samples the animations 12:12:11 majidvp: as birtles pointed out, time animations at the frequency of the rendering loop. there's this notion of the animation being dirty based on timeline input and how often you want to sample which is usually based on a vsync or the rendering loop 12:12:24 majidvp: for scroll timeline your timeline is only dirtied when things scroll, but you can sample it when you want 12:12:35 majidvp: for us, we mark it as dirty, but we only sample the animation when there is rendering 12:12:43 smfr: ok 12:13:15 birtles: also some things can change timing properties, typically we update the timelines at the beginning of a tick, run raf callbacks etc. changing anything about the timing could affect the ultimate progress value 12:13:39 smfr: so lets say you have a worklet which wants to output a step function, its input is continuously dirty and the output should only be occasionally dirty 12:14:04 birtles: we record the progress the last time we called, that way if we have multiple changes we don't duplicate work 12:14:58 flackr: it's worth noting the stale values model doesn't have to be the case since we could call the worklet and wait for the result 12:15:20 smfr: i'd like to see animationworklet be one particular implementation of webanimations. a naive model could be a quantizer, etc 12:15:45 majidvp: right now that placeholder is actually the animation. Maybe we need more wording around when the state of the animation is dirty 12:16:05 majidvp: it's perhaps not clear when inputs change or outputs change when you're required to sample these things 12:16:35 ikilpatrick: I think about it that web animations level 1 describes one internal animation run for how you receive timelines and how inputs change and worklet animations replaces that whole timeline 12:16:41 smfr: that's more significant than i was thinking 12:16:52 smfr: I was thinking maybe you take the whole animations graph and run that graph off thread 12:17:14 smfr: the model we're talking about now is you modify that timeline on the main thread and then run things off the main thread? 12:17:41 majidvp: group effects allow you to combine effects, they're not group animations, which would simplify things quite a bit 12:18:06 majidvp: the only place animations actually interact is during effect stack resolution. Multiple animations can be outputting to the same property and that's where you have to resolve that 12:18:30 majidvp: right now for example, if we detect that there are two animations writing to the same property we don't put it on the compositor, because you need to resolve the values at the end of it 12:18:47 majidvp: what we have with the current notion of animationworklet, animationworklet using the stale value allows you to combine these things 12:18:55 smfr: does level 2 allow for hierarchical timelines? 12:19:23 birtles: no. initially we tried having a graph with different modes but we ran into a lot of problems with that 12:19:39 birtles: most animation frameworks restrict play controls to the root node, i.e. pausing and rewinding 12:19:45 smfr: how would an effect hierarchy work? 12:20:05 birtles: animation control runs at the root, passes its time down to the next node. The groups calculate their time based on their children and pass a portion to each children 12:20:10 smfr: i see, so that's for sequencing, etc 12:20:27 birtles: then you can use delays like a negative start delay to modify start times 12:20:36 smfr: so the only way worklets feed into that is by modifying time values 12:21:02 majidvp: yes, so for example given a group effect, we want to hook directly to the time value of children. You could feed the time value to the top of the hierarchy or potentially reach directly into each child time 12:21:27 graouts: this would be valuable for transition effects, because you don't want to necessarily generate 200 animations ahead of time but rather receive a progress and say where children are 12:21:36 smfr: that breaks the concept where a worklet is modifying a single time value 12:22:15 majidvp: yes, but we imagined it as a more generic abstraction of GroupEffect which doesn't have to be parallel or sequence which is one way of describing interesting more powerful effects 12:22:39 majidvp: you just provide the grouping without any particular scheduling of sub effects, and animation worklet just outputs time values which are not necessairly parallel or seequential 12:23:09 graouts: another way of looking at it, there isn't actually group effect in any way, you just delegate the application of the timing model to a worklet which implements this behavior 12:23:34 graouts: I've been meaning to bring this to the group, we'd like to allow the web animation api to be used by javascript objects 12:23:51 graouts: web animations knows how to write these values, you should be able to just take a progress and do soemthing with that 12:24:22 graouts: there's a similarity here, you want to have one single thing act as the needle to feed input to particular effects. the trick is how can you do this effiicnetly which is what we're trying to solve with animation worklet 12:24:50 birtles: we used to have this custom effect, but we simplified it down to just a one sample callback, for things like updating strings where over time you want to change a number - something you can't easily do with just a number 12:25:05 birtles: this is in level 2, but it's a totally different extension, hanging off the effect 12:25:19 majidvp: right now animationworklet just allows you to register an animator, but you could register an effect 12:25:30 majidvp: because it's sandboxed you could run it off of the main thread 12:25:46 majidvp: in the sample callback you could for example make an http request, but once it's in this worklet scope ... 12:25:59 graouts: I agree extension points need to have a detailed scope so you can reason about what it can do 12:26:02 birtles: that's what you want sometimes 12:26:23 graouts: sometimes yes, but people who know what they're doing should have a clear idea about what work can be done and give that as input to the engine to do something smart with that 12:26:41 smfr: assuming it's pure output, it can just be a callback in javascript, that's fine, but we need a sandbox for more complex effects 12:27:25 graouts: libraries are just abstracting over writing to cssom, if we get a sandbox where we know what you can touch this is safe 12:27:53 ikilpatrick: you didn't like this because it's not how your style engine works. we previously had an applyHook which allows you to take computedstyle after style recalc and muck around with it, which i think is what you're describing 12:28:15 graouts: no, in my mind your library has its own model and you're just setting values on it. you just want to be told time has progressed and you can update your rotation to be 70 * 360 ... 12:28:26 graouts: you're the one who's setting the style 12:28:45 ikilpatrick: i think this is what animationworklet is giving you 12:29:05 graouts: you want to be animating a custom value like my property which is a number, and as that number is animated it tells you 12:29:17 graouts: it's different than a timeline, but has a lot in common 12:29:40 majidvp: right, it's right now that the web animation output is only style values but you're suggesting a keyframeeffect which outputs something other than style 12:29:49 graouts: and you may be changing a canvas element or a dom object 12:29:59 iank_: i see, instead of an element you've got some back door 12:30:19 birtles: we used to wrap that up in custom effect with an onsample callback 12:30:31 graouts: there are definitely different ways you could do it but its at the end of graph resolution 12:31:01 majidvp: another interesting idea is generalizing the notion of a time which can feed into a much richer graph of nodes rather than just progress values or simple time values 12:31:19 majidvp: you could feed in x and y coords for example which manipulate a 3d model in response to a finger 12:31:53 birtles: yeah, the thing that's concerning, we're looking at shipping this effect timing stuff and i'm wondering if we should move the concept of the time hierarchy to the animation end and just deal with fractional progress values before we ship this interface 12:32:27 iank_: that's one thing surma that you found playing around with animationworklet api difficult, localTime was weird and you expected progress, right? 12:32:47 surma: it took some getting used to. i was mostly concerned about the array thing but global time was fine. It's fine to keep the time metaphor in the developers head. 12:33:27 surma: not sure if it was spec or impl but we were rounding to microsecond resolution which meant that when i defined 0 to 1 turned into 0 to 1 ms which caused rounding errors and jittery animations 12:33:35 surma: so pretending that it was still time caused these issues 12:33:58 birtles: bringing up the dev mindset thing, if you've got 3 things that happen and they take 3s each, if you've got a time it's very natural to think of 12:34:25 birtles: if we switch to progress then you have to think about fractions , i.e. 0.33 12:34:39 graouts: thing is, if you're thinking in time, then time based api will be much better 12:35:07 birtles: which is the more natural way? absolute values (times) vs percentage values (proportions) 12:35:19 birtles: i.e. do you calculate the overall time from the components? 12:35:23 majidvp: that's a good question 12:35:36 birtles: I think scroll from a proportioning perspective makes sense 12:36:06 surma: i think if you're doing more complex things you want to choose numbers that are nice even things, for example I just chose 0 to 10000 for my scrolltimeline and doing math to convert which resulted in awkward numbers 12:36:31 surma: having to define the max time is beneficial to keep the numbers easy to work with 12:38:31 ant1: Should we be discussing the adgenda, but also value to have the open discussion. 12:38:45 majidvp: I think this is fine, fine if you want to move to more concrete 12:39:03 ant1: Was curious, with what you have in mind with schedules, agressively more forward? 12:39:38 majidvp: A little agressive on it, goal to enable this interactive effect, anim worklet is first step, then more interesting inputs, then interesting outputs, 12:40:27 majidvp: have impl, on stable, goal for next 6mo. stabilize impl, do origin trial, get feedback, bring this feedback back to the WG. Trying to make sure the overall arch. makes sense. 12:40:53 ant1: I think we need to have our own discussion about it to provide feedback. 12:41:09 majidvp: if someone from apple is interested and wants to be co-editor, that'd be great. 12:41:27 majidvp: Could also help drive the webanimations level2 features as well. 12:41:41 majidvp: Being agressive with it, good not to fall behind level 2. 12:42:28 flackr: If we had richer timelines, we could do everything that we were doing with animation worklet today. 12:42:41 birtles: I don't think effect is the right level. 12:42:51 flackr: Scroll would come into as a timeline. 12:43:23 birtles: I think you are mixing scroll and time it should be happening at the root. 12:43:41 majidvp: You actually want to control the playback of the effect. Its the animation that actually knows that. 12:44:06 flackr: Makes more sense where it is as an animation. 12:44:31 majidvp: Its a very natural node in the graph to do powerful things. 12:45:04 majidvp: You do need to have generalized time, to do interesting things, but at the moment we can get away with simple time, but want more later. 12:45:39 smfr: I still want to get back to the model where webanimations defines lots of specific apis. Animation worklet might have many hooks into all the different places. 12:45:52 majidvp: What do we need to change in the spec for all these hooks. 12:46:14 birtles: "call me every time the value of this node changes" hook 12:46:30 birtles: easing is something we've talked about previously. 12:46:38 birtles: Potential extension point. 12:47:47 birtles: some other way to provide inputs to the graph, i.e. input time values, either custom timeline, or animation worklet, something that takes a timeline, and ... 12:49:28 iank_: I think it was very powerful that worklet animation takes the input, and replaces the model, and drives the output directly. 12:50:12 majidvp: I thought the spec does provide that hook, the animation concept is the thing to replace, maybe i should define the input to that animation, and then the output. 12:50:24 smfr: The goal for webanim2 to define these extension points. 12:51:20 birtles: 12:52:01 ant1: one usecase might be tooling 12:52:08 majidvp: Lets close this discussion. 12:52:53 birtles: another request we've had is to see the contribution that an individual keyframe has rather than target output value 13:04:30 birtles: for shipping webanimations there's 3 main issues 13:04:54 birtles: 1st - what do we do about forwards filling animations? you can easily get thousands 13:05:04 birtles: technically we need to represent these in some way 13:05:20 birtles: naive way would be to keep all of them, so getAnimations gets back everything affecting animated style 13:05:42 birtles: this is obv not desirable, but is what we do in firefox today and there's a demo on the greensock page where firefox is much slower because of that 13:05:53 birtles: you don't have the same issue with css animations because you usually cancel the old ones 13:05:58 graouts: how can you remove them though? 13:06:07 graouts: they certainly exist in the implementation 13:06:17 birtles: the bare minimum is their effect still has to remain 13:06:43 birtles: there should be some way to tell what animation is doing to an element due to 500 forwards filling animations you need to be able to tell its doing so because of an animation 13:06:50 birtles: and you should be able to cancel that animation somehow 13:06:54 birtles: you shouldn't get stuck 13:07:16 birtles: we've gone through lots of proposals, keep thinking there's some simple answer but we keep coming back to this one solution 13:07:41 birtles: you have a fill animation which is mostly read only but represents all of the forwards filling animations that we could coalesce into one, and you can cancel that and it cancels all of the animations 13:07:52 birtles: that's the basic proposal, then just have a bunch of rules about how to make that make sense 13:08:10 birtles: for example, if you're holding onto an animation, and you call getAnimations, what happens if you cancel the one you're holding onto? 13:08:30 birtles: i think there's fairly obvious rules, but it gets complicated because of these partially coalesced bits of state, especially with composite modes 13:08:46 birtles: where some of the effects combine with what's below them and some of the things below them may still be running 13:08:57 birtles: so i've updated the issue thi smorning with some basic idea of what the rules would be 13:09:16 birtles: so i wanted to see if this was the right solution or if there's something simpler 13:09:22 smfr: is it a fault of the api? should the api be changed? 13:09:33 smfr: i.e. maybe there should be replace animations instead of just adding? 13:09:47 birtles: yeah, some of the apis do make you do very explicit things, but it doesn't work very well with compositing 13:10:09 birtles: especially the sort of thing where the mouse moving triggers a new animation on each mouse move where the start is implicit and the endpoint is absolute 13:10:14 smfr: you just keep accumulating? 13:10:24 birtles: yes, downside being you have thousands later on 13:10:35 smfr: i guess the alternative is to represent fill:forwards in a different way 13:10:52 smfr: like maybe say that the animation will donate it's fill: forwards to ?? 13:11:03 birtles: there was one api where you had to call some explicit thing to make it remain 13:11:17 smfr: it's unfortunate animations don't get gc'd 13:11:21 birtles: with this proposal they could be 13:11:29 graouts: essentially want something that behaves like transition 13:11:42 graouts: where you have a transitional behavior but you've already committed to that property 13:11:58 graouts: we could have a version of .animate that does that, which doesn't return anything 13:12:19 graouts: i think it is an extremely common case that people want to write 13:12:44 graouts: i think that's something we solved with webanim but it does seem like a common use case to say that this is now the truth value 13:13:07 graouts: wouldn't that be the first thing sets style in a definite manner but it doesn't show up right away 13:13:13 birtles: but what does it set? 13:13:34 graouts: i don't have a solution for this problem 13:14:02 birtles: DOesn't really work for the compositing case 13:14:50 ant1: Is this a problem.... is it so that a use-case where we run into this prob, too many animations, becomes unweildy, is it valuable to an author to reuse animations, e.g. a factory. 13:15:07 ant1: Then you are welcome to get an existing animation, and re-use it. 13:15:40 ant1: It could behave that way with an additional options in the arg dict. 13:15:56 an1: lots of stale animations still... that won't solve that problem. 13:16:12 birtles: It could work... but sometimes wants lots of anims stacking. 13:16:29 ant1: At this stage of the game if you want to ship something this year... 13:16:42 birtles: Hardest part is writing the tests for all the permuations. 13:17:17 ant1: If we think that this appraoch is worth while, concern with opt-out is that people wont observe the perf problem 13:17:24 birtles: If we think that this appraoch is worth while, concern with opt-out is that people wont observe the perf problem 13:18:04 birtles: This proposal getAnimations will return the fill aniamtion... 13:18:28 flackr: Any fill-fwd anim that is completely replced, you just cancel it as no ... 13:18:36 ant1: What if you cancel the anim on top? 13:18:42 flackr: You'll get the wrong behaviour. 13:18:53 birtles: Even that is complicated, have to match up prop by prop. 13:19:28 ant1: Could you have a concept of animations, instead of fill behaviour, "forever" anims, "fill-fwd" anims - but will be eventually removed, 13:20:11 ant1: If you knew the 2nd one was at some stage cancellable... then could do interesting things. 13:20:50 iank_: 13:20:59 flackr: 13:21:16 ant1: How likely is this for same property? 13:21:23 flackr: Yeah pretty common... 13:21:38 birtles: Has that complexity you need a map of what properties have been overridden. 13:22:31 flackr: If you can cancel you can never throw away that value.... 13:23:10 smfr: If you made it explicit? provide a callback that if you did nothing animation would get removed, but author can keep it around... 13:24:37 iank_: 13:24:48 flackr: birtles original proposal... 13:24:52 smfr: What was proposal? 13:24:55 https://github.com/w3c/csswg-drafts/issues/2054 13:25:07 flackr: When you call getAnimations you get a special animations type. 13:25:39 flackr: coaleesefsedfs animations that they web dev. doesn't have refs to.... 13:26:15 birtles: In that issue outlined my recollection about what we discussed, and worked example. 13:26:58 birtles: Slightly award thing is that everything throws, except cancel. 13:27:12 birtles: can call getKeyframes, etc. to see what it is settting. 13:27:29 majidvp: If you have two animations that are fill-fwd on two props. 13:27:41 majidvp: So this anim-type just has one anim? 13:28:09 ant1: transitions, & css non coalasdfas? 13:28:12 birtles: yes. 13:28:46 (coalasdfas == coalesce) 13:29:43 13:30:07 majidvp: You can't say there is at most fill animations, different engines coalesce at different times? 13:30:22 birtles: Internal coalesce of different animations.... 13:30:38 birtles: Even at the time of getAnimations.... 13:31:19 iank_: 13:31:29 birtles: 13:31:42 smfr: Different class? 13:31:54 birtles: Different subclass of aniamtions. 13:32:02 ant1: Are these read only? 13:32:12 birtles: Could introduce animation readonly. 13:32:57 birtles: Same shape an animation, something that dups it? 13:33:24 smfr: DOn't you need to specify this for remove? Or cancel? 13:34:12 ant1: CoalesceAnimation subclass...? 13:34:59 birtles: In CA how does remove work? 13:35:26 https://developer.apple.com/documentation/quartzcore/caanimation/1412458-removedoncompletion 13:35:26 birtles: I think at some stage it was remove on completion.... 13:35:36 ant1: It just sets a property on it. 13:35:44 ant1: Def. remove on completion... 13:36:07 smfr: so resolving to do the coalescing thing? 13:36:18 birtles: we'll give it a try, we can have web platform tests to end up with the same behavior 13:36:40 flackr: i agree, i think we want tests to explicitly test the coalescing 13:36:48 graouts: so a UA must implement coalescing 13:36:51 birtles: yes 13:37:20 flackr: it's worth noting you need to in=mplement the interface but you don't have to internally coalesce righ taway 13:37:51 birtles: next issue, what is the result of calling getKeyframes on a CSS animation effect? 13:38:02 birtles: there's some tricky bits like shorthands and variables 13:38:43 birtles: for example, if you were to just set your to keyframe to margin-left: 10px margin-top: 20px... 13:38:59 birtles: if you use shorthands in your keyframes you'd like to get shorthands back 13:39:07 graouts: how would you know order? you'd like to have a diff structure 13:39:21 birtles: if you do shorthand followed by longhand you could represent it with a dictionary 13:39:37 birtles: but if they're in the other way, where longhand gets clobbered bby shorthand we could drop the longhand 13:40:12 birtles: with variables for css animations, we could expand everything to landhands and resolve it there, but then you get a more complex representation than what you specified 13:40:20 graouts: we haven't considered that a problem 13:40:40 smfr has left #fx 13:40:47 smfr has joined #fx 13:40:51 graouts: when you use the api and you specify things yourself it makes sense that you want the same thing back, but to me, when you're querying css animations and transitions you're getting a representation of something provided through an incompatible system 13:41:02 graouts: getKeyframes is talking to a translation of CSS 13:41:22 graouts: so while it's nice to make best effort, it's not a requirement to do something nice 13:41:29 graouts: the spec could just say longhands for everything 13:41:50 graouts: what you've passed from css is gone 13:42:12 graouts: don't think this is a problem worth solving in a smarter way 13:42:26 graouts: it's fine if we have a better way, we could 13:42:50 birtles: there are other issues for getKeyframes 13:42:57 github: https://github.com/w3c/csswg-drafts/issues/2204 13:43:34 birtles: in css animations you can animate from underlying value to absolute value using an easing function 13:43:47 birtles: how do we represent an implicit value with an easing function? 13:44:01 birtles: normally you can have implicit keyframes, but there's no way to specify a keyframe level easing 13:44:25 birtles: flackr and i were talking about this, and one idea is to expose a null value to represent the underlying value 13:45:02 birtles: the example is in the issue, e.g. {marginLeft: null, steps: 5} 13:46:22 smfr: is this handling the case where a property may be missing, and combines with timing functions inside of the keyframes 13:46:49 birtles: yes, the webanimations model closely matches this, the weird problem is just applying a timing function to an implicit keyframe 13:47:18 birtles: i thought we could use additive animation, but that doesn't help for discretely animated properties, like auto sizing, what do you say for your underlying value 13:47:59 birtles: in firefox we use null internally but at the point where you call getKeyframes we substitute in the underlying value 13:48:03 birtles: but it's not actually correct 13:48:21 flackr: just not correct in that if you were to reapply that it wouldn't have the same effect 13:48:24 birtles: yeah 13:49:02 ericwilligers has joined #fx 13:49:21 smfr: sort of feels like you're reinventing cssom 13:49:31 smfr: maybe see if TabAtkins has opinions 13:49:53 Should I come in? 13:49:56 birtles: we need something to pass in 13:50:23 TabAtkins: we're just reinventing cssom, nothing to see here 13:50:30 (not actually tab that said that) 13:50:47 (standard is to use a comma instead of a colon to distinguish it from minuting) 13:51:37 birtles: there are two specs to specify a pseudo element 13:51:48 https://drafts.csswg.org/css-pseudo-4/#csspseudoelement 13:52:03 topic: Shipping getAnimations() - PseudoElement progress? 13:53:59 birtles: maybe we need to talk to alan or fantasai about whether this is going to happen, but if not maybe we need to put the pseudo name alongside the target 13:54:05 graouts: which we'd be stuck with 13:54:35 birtles: the other one is in cssom but it seems to be gone 13:55:28 birtles: I'll talk to alan and fantasai and see if they think it will exist or not. we implement it in firefox, not shipped but just a skeleton interface 13:56:18 flackr: would it be crazy to target the element? 13:56:25 birtles: yeah, dev tools would be wrong 13:56:47 graouts: when we support psuedoelements we stop filling that string? 13:57:23 birtles: we'll have that problem in a lot of other places, like the css transition event which has target and psuedo as separate attributes 13:57:38 flackr: maybe it's not so bad if we have to break it in the future 13:58:10 graouts: if you do the right thing, you should always look at target and psuedo id, so you would still have a target 13:58:23 graouts: what can you not do on a psuedoelement that you can do on an element 13:58:31 birtles: can't append it to another part of the tree 13:58:37 graouts: can't set attributes.. 13:58:57 birtles: the other thing we wanted to do was call animate on the pseudoelement 14:00:15 flackr: we could also not have a target? 14:01:03 flackr: just for that element from getAnimations 14:01:13 birtles: we'll still need it for dev tools but we could expose it as a chrome only thing 14:01:30 flackr: i guess it depends what it needs it for 14:02:19 flackr: or we have another interface, AnimationTarget 14:02:44 graouts: that's not a stupid idea, we could in general have the idea that animations not just target elements 14:03:08 birtles: we had this interface, AnimationTarget, with element and pseudoelement in it but we didn't have the concept of mixins at that point 14:03:19 birtles: now that we have mixins we could do this again 14:04:44 graouts: i can check into whether we have this 14:05:36 graouts: thinking about it more, it might be better to not use element as the target and get something explicit out of it 14:05:48 graouts: the naive thing for devs to do might be to assume it is an element and try to do something that fails 14:06:12 graouts: it might be safer to have an intermediate object 14:06:51 graouts: i assume the interface just as element and psuedo on it 14:07:14 flackr: yes, that's what i was proposing 14:08:10 krit: as a js developer can you get back to the element? 14:08:33 birtles: on this wrapper, you also have animate/ 14:08:38 graouts,flackr: yes 14:09:14 flackr: it just simplifies the simple things you might want to do relating to that animation 14:09:31 birtles: and then the constructors take an element, psuedo or this wrapper? 14:09:43 graouts: sure, so we need to pass it in 14:10:26 birtles: it's a little bit of extra api surface but it seems alright 14:10:38 graouts: we can always keep this under consideration and discuss further 14:11:02 graouts: unless smcgruer thinks its terrible 14:11:10 flackr: i don't think it adds significant complexity 14:11:33 birtles: when you know that you're targeting an element you have to add one extra link in the chain 14:11:52 graouts: in the longrun it may be better that we can target things other than elements 14:12:07 birtles: can do this with a mixin too 14:12:19 majidvp: what's wrong with a mixin? 14:12:53 birtles: it's possible to author content assuming its an element, and fail 14:13:51 flackr: but you couldn't do a mixin until pseudo is defined right? 14:14:15 birtles: might be able to do something .... 14:14:31 majidvp: event interface has a target which returns an EventTarget mixin 14:14:38 majidvp: which is Window, Element, etc 14:15:13 graouts: but you can't get events on it? 14:15:22 flackr: yes, through the bubble 14:15:34 majidvp: pseudoelements implement EventTarget 14:15:43 majidvp: so i think we should follow 14:16:11 majidvp: AnimationTarget is an interface implemented by Element or PseudoElement 14:16:58 birtles: I think we can change back to Animateable interface 14:17:37 birtles: firefox doesn't implement the rest of the psspseudoelement interface, the rest is empty 14:17:48 graouts: we just have a testing internal method to check if something is a pseudo element being animated 14:17:56 graouts: the only thing we expose is through a string like on transition events 14:18:08 majidvp: so we can ship webanimations without returning animations on pseudo 14:18:12 birtles: no, don't want to do that 14:19:20 majidvp: you could have an intermediate opaque handle which implements animationtarget which can be passed back into animation methods 14:19:32 majidvp: but you can't do anything else with it, so not blocked by pseudoelement shipping 14:19:57 majidvp: i think it's more ergonomic than having a wrapper 14:21:16 flackr: what if we just return an interface for pseudo? 14:21:45 birtles: i think just call the interface PseudoElement with a type 14:21:59 flackr: seems fine 14:22:38 birtles: parentElement is not in the spec 14:24:09 majidvp: think you shouldn't make concessions for pseudo 14:24:21 flackr: i think we're in agreement to do something like this 14:24:25 graouts, birtles: yes 14:25:02 topic: Clarification about "make animation’s start time unresolved" 14:25:16 github: https://github.com/w3c/csswg-drafts/issues/2359 14:25:51 graouts: i think i just misread the spec 14:26:05 graouts: there is actually a procedure to set the start time, maybe we want to clarify this but maybe it's fine 14:27:08 birtles: it's got this requirement that it should be implementable in non scripted interfaces that came from dimi? 14:29:29 graouts: another issue is that setTiming doesn't do invalidation and so you can end up with an animation held for eternity 14:30:03 birtles: yeah, we should make it explicit that you update the state 14:31:19 graouts: i'll raise an issue about this 14:38:29 graouts: one more thing we wanted was using a timeline attached to a media source 14:38:30 topic: timeline's attached to a media source 14:38:37 graouts: one more thing we wanted was using a timeline attached to a media source 14:38:53 graouts: it's tricky right now because you don't have a timeline with a writable time, so you have to go through all the animations and set them 14:39:40 krit: what about media source controls for background animations, etc? 14:39:57 graouts: sure, we hadn't thought about this because we're mostly syncing with media 14:40:23 graouts: for example subtitles could be decsribed with this or graphical improvements 14:40:42 graouts: there are specs around this concept 14:40:47 graouts: timetext 14:40:49 krit: ttml 14:41:16 majidvp: a scrolltimeline is essentially this, inherits from animationtimeline making it a kind of timeline with currenttime linked to scroll offset 14:41:43 graouts: sure, I was just bringing this forward as something we'd like to do sooner or later 14:42:17 birtles: all of this feels like you want media to take the place of animation. for example, what if you have media playing and an animation attached to that timeline, what do you expect to happen? 14:42:29 graouts: maybe then the animations get a slightly different behavior 14:42:41 flackr: or maybe it starts playing the video? 14:42:49 graouts: there are def things to think about 14:43:14 birtles: or animationworklet could serve as this adapter 14:43:28 graouts: yeah but ideally you want something declarative to be able to do things at a lower level 14:44:07 majidvp: how destructive will it be to have different types of animations with different playback animations 14:44:21 birtles: yeah, it sort of doesn't make sense to pause animations tied to other timelines 14:44:33 birtles: maybe there's some sort of mode switch where you're slaved to your timeline 14:44:47 graouts: there's a big difference because a documenttimeline never ends 14:45:11 birtles: for scroll timelines you have the same sort of issue if you pause animations while scrolling down the page 14:56:38 AmeliaBR has joined #fx 16:00:34 Zakim has left #fx