- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 May 2018 03:32:58 -0400
- 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