W3C home > Mailing lists > Public > www-style@w3.org > May 2018

Minutes Berlin F2F 2018-04-11 Part IV: Web Animations [web-animations]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 17 May 2018 03:32:58 -0400
Message-ID: <CADhPm3s36ErpAZjAinmYQWfWBT9Vep1c6aBkhSNjGVBcZBFjDA@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


Web Animations
--------------

  - Implementations are in progress for Animations and there were
      several pieces of implementor feedback discussed.
      - The spec naming around timelines are currently all about time,
          but there's interest in having it more about progress.
          However, it may be too late to change due to implementations
          that have shipped.
      - Querying the main thread for state will be similar to how
          threaded scrolling.
      - In Level 2 there is interest in exposing a web animation api
          to be used by javascript objects.
      - The focus of Level 2 will be to offer extension points to the
          core specified in Level 1.
  - UA must implement coalescing for forward filling animations (Issue
      #2054)
  - Most people felt that returning the longhand to getKeyframes()
      would be sufficient, though doing better would be nice.
  - Issue #2359 (Clarification about "make animation’s start time
      unresolved") came from misreading of the spec, but raised a
      different problem that setTiming doesn't do invalidation so a
      separate github will be opened.
  - There's a desire to have a timeline attached to a media source but
      there are several possible solutions that need to be evaluated.

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Breakout Agenda:
https://docs.google.com/document/d/1j3oeLpgX6kneG9lEgZQ80kitdyN-vbAYGPiwtYyN3tw/edit#

Scribe: flackr

Schedule Note: During this time block the group split into two
    sessions, one for CSS Text (see Part III of minutes) and this
    session based on CSS Animations

Web Animations
==============

  birtles: We're implementing web animations 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
  birtles: There's a few things we need to address, mapping between
           css animations and web animations.
  birtles: Another is pseudo elements and how to represent them.
  birtles: We were expecting a ?? api on the web platform by now but
           this hasn't happened yet.

AnimationWorklet Implementation Feedback
----------------------------------------

  birtles: Let's start with AnimationWorklet.
  majidvp: AnimationWorklet was previously similar to paintworklet,
           you would input style, and output style values directly.
  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.
  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
  majidvp: We allow the authors to replace this with a function which
           inputs time and outputs time.
  majidvp: This allows you to do animations off thread, with state.
  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.
  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
  majidvp: We have a whole set of examples: scroll -inked examples,
           examples with state, pull to refresh--which coordinates
           handoff between timelines
  majidvp: These can all be done without a lot of complexity inside
           AnimationWorklet.
  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.

  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 scrolling control time
  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
  majidvp: This can also feed into custom animations / animation
           worklet, allowing you to use scroll offset.
  majidvp: There's the possibility to have richer timelines such a
           pointer timeline or touch timeline.
  majidvp: I have a separate proposal to generalize the timeline
           proposal, the timeline currently is only a double.
  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
  majidvp: These are all experimental. For scroll we have an easy way
           based on the scrolltimeline proposal

  smfr: There's two ways of thinking about this, time could be
        progress or time could be time.
  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
  birtles: It says in the introduction that these time values normally
           represent time but maybe we shouldn't call it time.
  graouts: Reality is that right now everything is time.
  birtles: But we really just want progress
  birtles: Progress is really a fraction between 0 and 1 and start
           times are outside of that range
  birtles: We'd have to think about the term a bit
  birtles: Maybe it's worth rethinking but we've already shipped
           interfaces based on the naming
  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 compartmentalize
           these things as a phase which just uses these inputs to
           produce times
  graouts: Current time would be the local time for an animation
  birtles: I think in level 2 that's exposed

  graouts: Looking at the AnimationWorklet spec. I'm thinking about
           producing these values for a timeline in a more declarative
           way
  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
  graouts: We might want something more abstract
  surma: Is that currently a possibility?
  graouts: No, but I don't mean about animation particularly
  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
  majidvp: We should go back and work this out to be more flexible
  majidvp: It's very easy to do the wrong things with this
  majidvp: Normally animations, when you call play, record their start
           offset, but this doesn't make a lot of sense for scroll
           linked animations
  majidvp: This notion of progress helps make things make more sense.
           The progress comes from the time or the scroll timeline

  smfr: Does a scroll-linked animation behave like a scroll-linked
        animation with a rate of 0 and you scrub through it
  majidvp: Yes
  birtles: The playbackRate is still 1, but it doesn't get any updates
           until you scroll
  surma: playbackRate doesn't really make sense
  smfr: If you want to multiply around the scroll rate you would do
        that programmatically?
  birtles: You could use rate
  smfr: Another difference is the model that drives the animation.
        I.e. does a scroll linked animation tick at 60fps?
  majidvp: Yes, we think so, to avoid burning cycles

  surma: Should we spec this or is it just an optimization?
  graouts: The API doesn't expose anything related to an actual tick
  smfr: Is it implicit that there's a 60fps clock?
  surma: I think the intention is that we can do frame perfect effects
  birtles: The current model is through the document timeline, which
           is from the html spec is a step where you update the
           timelines associated with the document
  smfr: When does html spec update document?
  smfr: i.e. doesn't tick regularly
  birtles: It's just spec'd that the browser will update the
           rendering, so we need to spec when the scrolltimeline gets
           updated

  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
  birtles: I tried to do it that way but Domenic requested the other
           way around, with a hook to call from webanimations
  smfr: html5 spec already has problems around not specifying how
        requestAnimationFrame works
  birtles: We could add something for scrolling or more generic

  smfr: Do worklets act as a node in a time graph, which then output
        just a new time?
  majidvp: Yes, that's what makes it fit nicely with the model, it
           uses the normal flow of information in the webanimation
           graph
  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.
  smfr: This off the main thread is an implementation detail
  everyone: agrees

  iank: We have to put one on the main thread as well
  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
  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
  smfr: The existing webanimation spec allows users to poke transforms
        off the main thread
  flackr: I don't understand the concern because you can only look at
          your input times so you couldn't trigger an animation from
          that context
  smfr: If the main thread is blocked, but your worklet is running and
        spits out new values will you see transforms change?
  smfr: Does the web animations spec require a main thread step before
        it can change transforms?
  majidvp: It's similar to how we do composited animations right now,
           the compositor thread can be ahead
  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
  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
  surma: It has a snapshot of the most recent values
  majidvp: Similar to threaded scrolling

  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
  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
  birtles: Can you run AnimationWorklet both on the main thread and on
           the compositor in parallel?
  flackr: You can actually run it synchronously
  surma: The worklet concept allows that but the spec doesn't
         currently prescribe that
  majidvp: Technically you can run two copies, with different state
  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
          synchronously wait for the result
  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
  smfr: This gets back to the update model, how often does a worklet
        run?
  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
  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
  majidvp: For scroll timeline your timeline is only dirtied when
           things scroll, but you can sample it when you want
  majidvp: For us, we mark it as dirty, but we only sample the
           animation when there is rendering
  smfr: ok
  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
  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
  birtles: We record the progress the last time we called, that way if
           we have multiple changes we don't duplicate work
  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

  smfr: I'd like to see AnimationWorklet be one particular
        implementation of webanimations. A naive model could be a
        quantizer, etc.
  majidvp: Right now that placeholder is actually the animation. Maybe
           we need more wording around when the state of the animation
           is dirty
  majidvp: It's perhaps not clear when inputs change or outputs change
           when you're required to sample these things
  iank: 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
  smfr: That's more significant than I was thinking
  smfr: I was thinking maybe you take the whole animations graph and
        run that graph off thread
  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?
  majidvp: Group effects allow you to combine effects, they're not
           group animations, which would simplify things quite a bit
  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
  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
  majidvp: What we have with the current notion of AnimationWorklet,
           AnimationWorklet using the stale value allows you to
           combine these things

  smfr: Does level 2 allow for hierarchical timelines?
  birtles: No. Initially we tried having a graph with different modes
           but we ran into a lot of problems with that
  birtles: Most animation frameworks restrict play controls to the
           root node, i.e. pausing and rewinding
  smfr: How would an effect hierarchy work?
  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
  smfr: I see, so that's for sequencing, etc
  birtles: Then you can use delays like a negative start delay to
           modify start times
  smfr: So the only way worklets feed into that is by modifying time
        values
  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
  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
  smfr: That breaks the concept where a worklet is modifying a single
        time value
  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
  majidvp: You just provide the grouping without any particular
           scheduling of sub effects, and animation worklet just
           outputs time values which are not necessarily parallel or
           sequential
  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

  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
  graouts: Web animations knows how to write these values, you should
           be able to just take a progress and do something with that
  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 efficiently which
           is what we're trying to solve with animation worklet
  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
  birtles: This is in level 2, but it's a totally different extension,
           hanging off the effect
  majidvp: Right now AnimationWorklet just allows you to register an
           animator, but you could register an effect
  majidvp: Because it's sandboxed you could run it off of the main
           thread
  majidvp: In the sample callback you could for example make an http
           request, but once it's in this worklet scope ...
  graouts: I agree extension points need to have a detailed scope so
           you can reason about what it can do
  birtles: That's what you want sometimes
  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
  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
  graouts: Libraries are just abstracting over writing to cssom, if we
           get a sandbox where we know what you can touch this is safe
  iank: 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
  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 ...
  graouts: You're the one who's setting the style
  iank: I think this is what AnimationWorklet is giving you
  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
  graouts: It's different than a timeline, but has a lot in common
  majidvp: Right, it's right now that the web animation output is only
           style values but you're suggesting a keyframe effect which
           outputs something other than style
  graouts: And you may be changing a canvas element or a dom object
  iank: I see, instead of an element you've got some back door
  birtles: We used to wrap that up in custom effect with an onSample
           callback
  graouts: There are definitely different ways you could do it but its
           at the end of graph resolution

  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
  majidvp: You could feed in x and y coords for example which
           manipulate a 3d model in response to a finger
  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
  iank: That's one thing surma that you found playing around with
        AnimationWorklet api difficult, localTime was weird and you
        expected progress, right?
  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.
  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
  surma: So pretending that it was still time caused these issues

  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
  birtles: If we switch to progress then you have to think about
           fractions , i.e. 0.33
  graouts: Thing is, if you're thinking in time, then time based api
           will be much better
  birtles: Which is the more natural way? absolute values (times) vs
           percentage values (proportions)
  birtles: i.e. do you calculate the overall time from the components?
  majidvp: That's a good question
  birtles: I think scroll from a proportioning perspective makes sense
  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
  surma: Having to define the max time is beneficial to keep the
         numbers easy to work with

  ant1: Should we be discussing the agenda, but also value to have the
        open discussion.
  majidvp: I think this is fine, fine if you want to move to more
           concrete
  ant1: Was curious, with what you have in mind with schedules,
        aggressively more forward?
  majidvp: A little aggressive on it, goal to enable this interactive
           effect, animations worklet is first step, then more
           interesting inputs, then interesting outputs
  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.
  ant1: I think we need to have our own discussion about it to provide
        feedback.
  majidvp: If someone from apple is interested and wants to be
           co-editor, that'd be great.
  majidvp: Could also help drive the webanimations level2 features as
           well.
  majidvp: Being aggressive with it, good not to fall behind level 2.
  flackr: If we had richer timelines, we could do everything that we
          were doing with animation worklet today.
  birtles: I don't think effect is the right level.
  flackr: Scroll would come into as a timeline.
  birtles: I think you are mixing scroll and time it should be
           happening at the root.
  majidvp: You actually want to control the playback of the effect.
           Its the animation that actually knows that.
  flackr: Makes more sense where it is as an animation.
  majidvp: Its a very natural node in the graph to do powerful things.
  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.

  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.
  majidvp: What do we need to change in the spec for all these hooks.
  birtles: "call me every time the value of this node changes" hook
  birtles: Easing is something we've talked about previously.
  birtles: Potential extension point.
  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 ...
  iank: I think it was very powerful that worklet animation takes the
        input, and replaces the model, and drives the output directly.
  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.
  smfr: The goal for webanim2 to define these extension points.
  birtles: <something about reading the actual output of the effect?>
  ant1: One usecase might be tooling.
  majidvp: Lets close this discussion.
  birtles: Another request we've had is to see the contribution that
           an individual keyframe has rather than target output value.

Forward Filling Animations
--------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2054

  birtles: For shipping webanimations there's 3 main issues
  birtles: 1st - what do we do about forwards filling animations? You
           can easily get thousands
  birtles: Technically we need to represent these in some way
  birtles: Naive way would be to keep all of them, so getAnimations
           gets back everything affecting animated style
  birtles: This is obviously 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
  birtles: You don't have the same issue with css animations because
           you usually cancel the old ones
  graouts: How can you remove them though?
  graouts: They certainly exist in the implementation
  birtles: The bare minimum is their effect still has to remain
  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
  birtles: And you should be able to cancel that animation somehow
  birtles: You shouldn't get stuck
  birtles: We've gone through lots of proposals, keep thinking there's
           some simple answer but we keep coming back to this one
           solution
  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
  birtles: That's the basic proposal, then just have a bunch of rules
           about how to make that make sense
  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?
  birtles: I think there's fairly obvious rules, but it gets
           complicated because of these partially coalesced bits of
           state, especially with composite modes
  birtles: Where some of the effects combine with what's below them
           and some of the things below them may still be running
  birtles: So I've updated the issue this morning with some basic idea
           of what the rules would be.
  birtles: So I wanted to see if this was the right solution or if
           there's something simpler.
  smfr: Is it a fault of the api? Should the api be changed?
  smfr: i.e. maybe there should be replace animations instead of just
        adding?
  birtles: Yeah, some of the apis do make you do very explicit things,
           but it doesn't work very well with compositing
  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
  smfr: You just keep accumulating?
  birtles: Yes, downside being you have thousands later on
  smfr: I guess the alternative is to represent fill:forwards in a
        different way
  smfr: Like maybe say that the animation will donate it's fill:
        forwards to ??
  birtles: There was one api where you had to call some explicit thing
           to make it remain
  smfr: It's unfortunate animations don't get gc'd
  birtles: With this proposal they could be
  graouts: Essentially want something that behaves like transition
  graouts: Where you have a transitional behavior but you've already
           committed to that property
  graouts: We could have a version of .animate that does that, which
           doesn't return anything
  graouts: I think it is an extremely common case that people want to
           write
  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
  graouts: Wouldn't that be the first thing sets style in a definite
           manner but it doesn't show up right away
  birtles: But what does it set?
  graouts: I don't have a solution for this problem

  Scribe: iank

  birtles: Doesn't really work for the compositing case
  ant1: Is this a problem.... is it so that a use-case where we run
        into this problem, too many animations, becomes unwieldy, is
        it valuable to an author to reuse animations, e.g. a factory.
  ant1: Then you are welcome to get an existing animation, and re-use
        it.
  ant1: It could behave that way with an additional options in the arg
        dict.
  an1: Lots of stale animations still... that won't solve that problem.
  birtles: It could work... but sometimes wants lots of animations
           stacking.
  ant1: At this stage of the game if you want to ship something this
        year...
  birtles: Hardest part is writing the tests for all the permutations.

  ant1: If we think that this approach is worth while, concern with
        opt-out is that people won't observe the performance problem
  birtles: If we think that this approach is worth while, concern with
           opt-out is that people won't observe the performance problem
  birtles: This proposal getAnimations will return the fill
           animation...
  flackr: Any fill-forward animation that is completely replaced, you
          just cancel it as no ...
  ant1: What if you cancel the animation on top?
  flackr: You'll get the wrong behaviour.
  birtles: Even that is complicated, have to match up prop by prop.
  ant1: Could you have a concept of animations, instead of fill
        behaviour, "forever" anims, "fill-fwd" anims - but will be
        eventually removed,
  ant1: If you knew the 2nd one was at some stage cancellable... then
        could do interesting things.
  iank: <jokes about UnCancellableAnimation>
  flackr: <also jokes around>

  ant1: How likely is this for same property?
  flackr: Yeah pretty common...
  birtles: Has that complexity you need a map of what properties have
           been overridden.
  flackr: If you can cancel you can never throw away that value....
  smfr: If you made it explicit? Provide a callback that if you did
        nothing animation would get removed, but author can keep it
        around...
  iank: <muses about complexity with number of animations you need to
        keep around>

  flackr: birtles original proposal...
  smfr: What was proposal?
  <birtles> https://github.com/w3c/csswg-drafts/issues/2054
  flackr: When you call getAnimations you get a special animations
          type.
  flackr: Coalesce animations that they web dev. doesn't have refs
          to....
  birtles: In that issue outlined my recollection about what we
           discussed, and worked example.
  birtles: Slightly award thing is that everything throws, except
           cancel.
  birtles: Can call getKeyframes, etc. to see what it is setting.
  majidvp: If you have two animations that are fill-fwd on two
           properties.
  majidvp: So this animation-type just has one animation?
  ant1: Transitions, & css non coalesce?
  birtles: Yes.
  <discussion about testing this feature>

  majidvp: You can't say there is at most fill animations, different
           engines coalesce at different times?
  birtles: Internal coalesce of different animations....
  birtles: Even at the time of getAnimations....
  iank: <clarifies behaviour of get animations, web dev. sees always
        coalesced values of animations>
  birtles: <discussion about processing model of running animations>
  smfr: Different class?
  birtles: Different subclass of animations.
  ant1: Are these read only?
  birtles: Could introduce animation read only.
  birtles: Same shape an animation, something that dups it?
  smfr: Don't you need to specify this for remove? Or cancel?
  ant1: CoalesceAnimation subclass...?
  birtles: In CA how does remove work?
  <birtles> https://developer.apple.com/documentation/quartzcore/caanimation/1412458-removedoncompletion
  birtles: I think at some stage it was remove on completion....
  ant1: It just sets a property on it.
  ant1: Definitely remove on completion...

  Scribe: flackr

  smfr: So resolving to do the coalescing thing?
  birtles: We'll give it a try, we can have web platform tests to end
           up with the same behavior
  flackr: I agree, I think we want tests to explicitly test the
          coalescing
  graouts: So a UA must implement coalescing
  birtles: Yes.
  flackr: It's worth noting you need to implement the interface but
          you don't have to internally coalesce right away

Shipping getAnimations() - getKeyframes() for CSS Animations
------------------------------------------------------------

  birtles: Next issue, what is the result of calling getKeyframes on a
           CSS animation effect?
  birtles: There's some tricky bits like shorthands and variables
  birtles: For example, if you were to just set your to keyframe to
           margin-left: 10px margin-top: 20px...
  birtles: If you use shorthands in your keyframes you'd like to get
           shorthands back
  graouts: How would you know order? You'd like to have a diff
           structure
  birtles: If you do shorthand followed by longhand you could
           represent it with a dictionary
  birtles: But if they're in the other way, where longhand gets
           clobbered by shorthand we could drop the longhand
  birtles: With variables for css animations, we could expand
           everything to longhands and resolve it there, but then you
           get a more complex representation than what you specified

  graouts: We haven't considered that a problem
  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
  graouts: getKeyframes is talking to a translation of CSS
  graouts: So while it's nice to make best effort, it's not a
           requirement to do something nice
  graouts: The spec could just say longhands for everything
  graouts: What you've passed from css is gone
  graouts: Don't think this is a problem worth solving in a smarter way
  graouts: It's fine if we have a better way, we could
  birtles: There are other issues for getKeyframes
  birtles: In css animations you can animate from underlying value to
           absolute value using an easing function
  birtles: How do we represent an implicit value with an easing
           function?
  birtles: Normally you can have implicit keyframes, but there's no
           way to specify a keyframe level easing
  birtles: flackr and I were talking about this, and one idea is to
           expose a null value to represent the underlying value
  birtles: The example is in the issue, e.g. {marginLeft: null,
           steps: 5}

  smfr: Is this handling the case where a property may be missing, and
        combines with timing functions inside of the keyframes
  birtles: Yes, the webanimations model closely matches this, the
           weird problem is just applying a timing function to an
           implicit keyframe
  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
  birtles: In firefox we use null internally but at the point where
           you call getKeyframes we substitute in the underlying value
  birtles: But it's not actually correct
  flackr: Just not correct in that if you were to reapply that it
          wouldn't have the same effect
  birtles: Yeah.
  smfr: Sort of feels like you're reinventing cssom.
  smfr: Maybe see if TabAtkins has opinions.

Shipping getAnimations() - PseudoElement progress?
--------------------------------------------------

  birtles: We need something to pass in.
  birtles: There are two specs to specify a pseudo element
  <birtles> https://drafts.csswg.org/css-pseudo-4/#csspseudo element
  birtles: Maybe we need to talk to astearns or fantasai about whether
           this is going to happen, but if not maybe we need to put
           the pseudo name alongside the target
  graouts: Which we'd be stuck with
  birtles: The other one is in cssom but it seems to be gone
  birtles: I'll talk to astearns and fantasai and see if they think it
           will exist or not. We implement it in firefox, not shipped
           but just a skeleton interface

  flackr: Would it be crazy to target the element?
  birtles: Yeah, dev tools would be wrong
  graouts: When we support pseudo elements we stop filling that string?
  birtles: We'll have that problem in a lot of other places, like the
           css transition event which has target and pseudo as
           separate attributes
  flackr: Maybe it's not so bad if we have to break it in the future
  graouts: If you do the right thing, you should always look at target
           and pseudo id, so you would still have a target
  graouts: What can you not do on a pseudo element that you can do on
           an element
  birtles: Can't append it to another part of the tree
  graouts: Can't set attributes..

  birtles: The other thing we wanted to do was call animate on the
           pseudo element
  flackr: We could also not have a target?
  flackr: Just for that element from getAnimations
  birtles: We'll still need it for dev tools but we could expose it as
           a chrome only thing
  flackr: I guess it depends what it needs it for
  flackr: Or we have another interface, AnimationTarget
  graouts: That's not a stupid idea, we could in general have the idea
           that animations not just target elements

  birtles: We had this interface, AnimationTarget, with element and
           pseudo element in it but we didn't have the concept of
           mixins at that point
  birtles: Now that we have mixins we could do this again
  graouts: I can check into whether we have this
  graouts: Thinking about it more, it might be better to not use
           element as the target and get something explicit out of it
  graouts: The naive thing for devs to do might be to assume it is an
           element and try to do something that fails
  graouts: It might be safer to have an intermediate object
  graouts: I assume the interface just as element and pseudo on it
  flackr: Yes, that's what I was proposing

  krit: As a js developer can you get back to the element?
  birtles: On this wrapper, you also have animate
  graouts,flackr: yes
  flackr: It just simplifies the simple things you might want to do
          relating to that animation
  birtles: And then the constructors take an element, pseudo or this
           wrapper?
  graouts: Sure, so we need to pass it in
  birtles: It's a little bit of extra API surface but it seems alright
  graouts: We can always keep this under consideration and discuss
           further
  graouts: Unless smcgruer thinks its terrible
  flackr: I don't think it adds significant complexity
  birtles: When you know that you're targeting an element you have to
           add one extra link in the chain
  graouts: In the long run it may be better that we can target things
           other than elements

  birtles: Can do this with a mixin too
  majidvp: What's wrong with a mixin?
  birtles: It's possible to author content assuming its an element,
           and fail
  flackr: But you couldn't do a mixin until pseudo is defined right?
  birtles: Might be able to do something ....
  majidvp: Event interface has a target which returns an EventTarget
           mixin
  majidvp: Which is Window, Element, etc
  graouts: But you can't get events on it?
  flackr: Yes, through the bubble
  majidvp: Pseudo elements implement EventTarget
  majidvp: So I think we should follow

  majidvp: AnimationTarget is an interface implemented by Element or
           PseudoElement
  birtles: I think we can change back to Animateable interface
  birtles: Firefox doesn't implement the rest of the CSS pseudo
           element interface, the rest is empty
  graouts: We just have a testing internal method to check if
           something is a pseudo element being animated
  graouts: The only thing we expose is through a string like on
           transition events
  majidvp: So we can ship webanimations without returning animations
           on pseudo
  birtles: No, don't want to do that
  majidvp: You could have an intermediate opaque handle which
           implements animationtarget which can be passed back into
           animation methods
  majidvp: But you can't do anything else with it, so not blocked by
           pseudo element shipping
  majidvp: I think it's more ergonomic than having a wrapper

  flackr: What if we just return an interface for pseudo?
  birtles: I think just call the interface PseudoElement with a type
  flackr: Seems fine
  birtles: parentElement is not in the spec
  majidvp: Think you shouldn't make concessions for pseudo
  flackr: I think we're in agreement to do something like this
  graouts, birtles: yes

Clarification about "make animation’s start time unresolved"
------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2359

  graouts: I think I just misread the spec
  graouts: There is actually a procedure to set the start time, maybe
           we want to clarify this but maybe it's fine
  birtles: It's got this requirement that it should be implementable
           in non scripted interfaces that came from dimi?
  graouts: Another issue is that setTiming doesn't do invalidation and
           so you can end up with an animation held for eternity
  birtles: Yeah, we should make it explicit that you update the state
  graouts: I'll raise an issue about this

timeline's attached to a media source
-------------------------------------

  graouts: One more thing we wanted was using a timeline attached to a
           media source
  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

  krit: What about media source controls for background animations,
        etc?
  graouts: Sure, we hadn't thought about this because we're mostly
           syncing with media
  graouts: For example subtitles could be decsribed with this or
           graphical improvements
  graouts: There are specs around this concept
  graouts: timetext
  krit: ttml
  majidvp: A scrolltimeline is essentially this, inherits from
           animationTimeline making it a kind of timeline with
           currentTime linked to scroll offset
  graouts: Sure, I was just bringing this forward as something we'd
           like to do sooner or later

  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?
  graouts: Maybe then the animations get a slightly different behavior
  flackr: Or maybe it starts playing the video?
  graouts: There are definitely things to think about
  birtles: Or AnimationWorklet could serve as this adapter
  graouts: Yeah but ideally you want something declarative to be able
           to do things at a lower level
  majidvp: How destructive will it be to have different types of
           animations with different playback animations
  birtles: Yeah, it sort of doesn't make sense to pause animations
           tied to other timelines
  birtles: Maybe there's some sort of mode switch where you're slaved
           to your timeline
  graouts: There's a big difference because a documenttimeline never
           ends
  birtles: For scroll timelines you have the same sort of issue if you
           pause animations while scrolling down the page
Received on Thursday, 17 May 2018 07:33:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 May 2018 07:33:57 UTC