- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 23 Nov 2015 20:16:37 -0500
- To: www-style@w3.org
Animations
----------
- Reaffirmed that for liveness, the right approach was:
- base values are interpolated values from all animations on
this element and on all elements on which its computed
values depend.
- base values are dynamic (i.e., if the expected value at a
future time changes the running animation changes to match)
- Remove the *onanimation Event Handlers because they're not needed.
- Leave pseudoElement of the AnimationEvent interface at risk - it
only has one implementation.
- The usage of elapsedTime Member will be examined to see if it
can be dropped.
- The current Gecko behavior will be specced for handling of
multiple overlapping animation names.
- Having multiple identifiers per @keyframes rule is a level 2
feature.
- A bunch of people seem to agree that animation-timing-function
doesn't cascade between keyframes. More specifically, that a
lack of animation-timing-function in a keyframe is an
affirmative request to use the value from the element, not
just a lack of declaration.
- Animation Type seemed like a good idea and there should be a
mass spec-edit to make the appropriate changes.
- There needs to be a comprehensive pass through of mailings lists
and github to make sure all issues, especially with
shorthands, were captured and addressed.
===== FULL MINUTES BELOW ======
[This discussion didn't occur in IRC, but instead used an etherpad
(linked below) for the conversation. The text below the IRC
conversation is copied from the etherpad. Also, as it is an
etherpad, there were multiple authors, not a designated scribe]
<astearns> reconvening to talk about css-animations issues, if we
can get a quorum to come back to the room
<birtles> https://lists.w3.org/Archives/Public/www-style/2015Oct/0222.html
<birtles> https://public.etherpad-mozilla.org/p/css-animations-issues-list
<astearns> (notes will be taken on the etherpad as we go)
<dbaron> G was relative to
http://lists.w3.org/Archives/Public/www-style/2014Aug/0132.html
<dbaron> https://github.com/w3c/csswg-drafts/pull/41
<dbaron> https://lists.w3.org/Archives/Public/www-style/2014Apr/0373.html
Animation
=========
1. Liveness
-----------
Two issues here:
(a) Base value liveness was resolved[1] to use the G-β variant from
[2].
Last I can see, Sylvain was requesting help writing spec text
for this.[3]
I'll note that the original proposal came with the caveat:
"I would not want to commit to (E), (F), or (G) without
somebody having implementation experience handling both the
repeating animations issue and handling sending such
animations to be run on the compositor."[1]
We've yet to implement this in Gecko[4] so I'm reluctant go
ahead with specifying this part just yet unless anyone else
has done so.
[1] https://lists.w3.org/Archives/Public/www-style/2014Oct/0290.html
[2] https://lists.w3.org/Archives/Public/www-style/2014Aug/0132.html
[3] https://lists.w3.org/Archives/Public/www-style/2014Oct/0393.html
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1064915
The Blink Web Animations & CSS Animations implementations do G-β.
Conclusion: this seems fine to spec. There were some issues
here: https://github.com/w3c/csswg-drafts/pull/41. They
probably won't prevent speccing though.
(b) Liveness of animation-* properties
Proposal was to make everything adjustable but to fix the start
time once it is resolved.[1]
One question was about whether the start time means the
beginning or the end of the delay phase.[2] David Baron's
suggestion was that it is the start of the delay phase. This
allows adjusting the animation-delay after the animation is
started and matches the Web Animations model where the delay
is measured from the start time.
When this was specced, however, it was taken to be the end of
the delay, that is, changes to the animation-delay are ignored
once the animation has started.[4] I think this is a bad idea
since it means animations behave differently depending on
whether or not a style flush was triggered before the
animation-delay was changed.[5]
This came up recently because people are updating the delay as a
way of seeking an animation for debugging.[6] This works in
Blink and Gecko but not Webkit. I'd like to update the spec to
remove the reference to snapshotting the animation-delay.
Event dispatch wording might need rework but we have a
generalized definition of that in CSS Animations 2 that we can
probably use and that agrees with the approach Tab outlined.[3]
[1] https://lists.w3.org/Archives/Public/www-style/2014Sep/0129.html
(see particularly the clarification in:
https://lists.w3.org/Archives/Public/www-style/2014Sep/0130.html)
[2] https://lists.w3.org/Archives/Public/www-style/2014Sep/0131.html
[3] https://drafts.csswg.org/css-animations-2/#event-dispatch
[4] https://github.com/w3c/csswg-drafts/commit/84f853d8b2c54ba8244de95b2e3aa8e8f337ad18
based on
https://lists.w3.org/Archives/Public/www-style/2014Oct/0309.html
[5] https://lists.w3.org/Archives/Public/www-style/2014Oct/0318.html
[6] https://css-tricks.com/debugging-css-keyframe-animations/ as
brought up here:
https://lists.w3.org/Archives/Public/www-style/2015Aug/0106.html
Conclusion: Fix spec to make animation-delay live
2. onanimation* Event Handlers
------------------------------
Blink and WebKit have these.[1] Ok to spec them?
I've prepared draft spec text (animation events only, so far).[2]
[1] https://chromiumcodereview.appspot.com/23583032/
[2] https://github.com/w3c/csswg-drafts/compare/animation-event-handlers
Conclusion: Not needed, should remove
https://drafts.csswg.org/css-animations/#event-handlers-on-elements-document-objects-and-window-objects
3. pseudoElement Member
-----------------------
The pseudoElement of the AnimationEvent interface is marked
at-risk.[1] Why is this? Are we hoping to use the
CSSPseudoElement interface instead?
[1] https://drafts.csswg.org/css-animations/#status
Conclusion: At risk because currently only Gecko implements it.
4. elapsedTime Member
---------------------
This definition needs clarification but it's hard to know what the
intended behavior is. Are there any use cases for this?[1]
It's useless for lining up Javascript animations with CSS
animations since it represents the ideal elapsed time, not the
actual elapsed time. (That is, if an animation repeats after 3s
but the first animation frame after that point is after 3.05s,
we'll still report an elapsedTime of 3, not 3.05.) So, what is
it good for?
[1] https://lists.w3.org/Archives/Public/www-style/2015Sep/0304.html
Dean: This is (probably) used to determine how many iterations
have happened.
Brian: Libraries using for feature detection so maybe can't remove.
Conclusion: Look at usage to see if it can be dropped.
5. Handling of multiple overlapping animation names
---------------------------------------------------
If I have:
animation: abc 5s;
And, while 'abc' is running on 'elem', I do:
elem.style.animationName = 'abc, abc';
Will the existing animation be mapped to the animation at the end
of the list or the one at the start?
This will be observable since you'll either see:
(a) The original animation continue to the end, then the last
part of the new animation run (assuming no forwards fill), or
(b) A new animation immediately start and run to completion.
If you match animation names from the end of the list (i.e.
effectively prepend the new animation), you'll get (a).
If you match animation names from the start of the list (i.e.
effectively append the new animation), you'll get (b).
In Gecko we currently do (a). The reasoning being that, "since
later animations in the list override earlier ones, the last
occurrence is most likely (though not certain, if it's not
currently running/filling) to be the one that's actually
influencing state"[1]
Testing with this pen: http://codepen.io/anon/pen/bVvJBO , Blink
and Edge appear to ignore multiple references to the same
animation.
Note that supporting multiple references to the same animation
name lets you restart animations on :hover (but doesn't let you
restart again when leaving the :hover state).[2]
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1037316#c4
[2] http://justmarkup.com/log/2015/01/26/restart-css-animation-using-css-to-trigger-a-reflow/
Conclusion: spec the current Gecko behavior
6. Restarting with the same name
--------------------------------
Lea Verou was wondering how we can start and restart animations
when we transition in *and* *out* of :hover.[1]
Is it worth adding something to animation-name syntax for
triggering animations?
https://lists.w3.org/Archives/Public/www-style/2015Oct/0174.html
Conclusion: Level 2 feature
Conclusion: Add to level 2 draft (at least add an issue)
Adding an identifier would also solve the previous issue with
regards to which animation to match
7. Keyframe handling
--------------------
Tab provided a revised description of how @keyframes rules
combine, specifically with regard to how animation-timing-
function values are applied.[1] It seems reasonable to me so I'd
like to try and spec it.
A couple of concerns, however:
(a) How animation-timing-functions inherit.
e.g.
@keyframes abc {
to { left: 200px, animation-timing-function: linear }
to { left: 300px }
}
Will animate to 300px with the computed value of the
animation-timing-function on the target element.
(i.e. this behaves the same as:
@keyframes abc {
to { left: 300px }
}
)
Conclusion: Sounds like a bunch of us seem to agree that
animation-timing-function doesn't cascade between keyframes.
More specifically, that a lack of animation-timing-function in a
keyframe is an affirmative request to use the value from the
element, not just a lack of declaration
(b) Shorthands.
For the step, "Divide the list of transition endpoints into a
number of independent lists according to the property
associated with the endpoint, maintaining the relative order",
is this supposed to work after expanding shorthands?
Conclusion: yes, expand shorthands first
[1] https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html
8. Specifying animation types
-----------------------------
We've talked about replacing the "Animatable" line in property
definition tables with "Interpolable".[1]
In Web Animations, everything is animatable unless animation is
explicitly prohibited (e.g. animation-* properties). The default
type of animation is "as string" which is basically discrete
interpolation such that the value changes at the midpoint.
Web Animations lets you do more than just interpolation but also
addition and accumulation.[2] For each property we can animate,
we need to define what each of those three things mean. Web
Animations calls that set of definitions the "animation
behavior".[3] I think "animation type" might be a better name,
however.
This is different to the CSS type since you might have two
different properties with <number> type but where one is allowed
to add and the other isn't.
Web Animations provides a few pre-defined "animation types
(behaviors)" such as "Animatable as string", or "Animatable as
real number". Specs can use one of these or define their own.
Perhaps the property definition table should say, "Animation type:
string"?
Conclusions:
> Just be careful that properties can list multiple types (but
it seems there's only one legacy example of this - line-
height) that don't interact with each other, in addition to
being able to list a compound type like "length, percentage,
and calc()"
> Animation Type sounds good.
> Should mass-edit specs to fix.
> Some specs (images, transforms, shadow) already have custom
animation behavior
[1] https://lists.w3.org/Archives/Public/www-style/2015May/0256.html
[2] http://w3c.github.io/web-animations/#procedures-for-animating-properties
[3] http://w3c.github.io/web-animations/#animation-behavior
9. Other issues?
----------------
* Are the shorthand issues resolved?[1][2]
* Possible issue around shorthands[3]
* Others?
Conclusions:
- https://github.com/w3c/csswg-drafts/pull/42 (with discussion
in 41; I think something there was actually pointing at some
missing text)
- Go through public-fx and www-style and look for more questions
- https://github.com/dbaron/gather-doc-email may be useful
- Check that everything in
https://lists.w3.org/Archives/Public/www-style/2012Nov/0261.html
was edited (although the non-interpolable values needs to be
done in transitions)
[1] https://lists.w3.org/Archives/Public/www-style/2014Dec/0340.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28053
[3] https://lists.w3.org/Archives/Public/www-style/2011Oct/0834.html
Received on Tuesday, 24 November 2015 01:17:40 UTC