Hi Aleksei,
On 2014/11/07 20:14, Aleksei Semenov wrote:
The default value for 'composite' attribute is specified as null (
http://w3c.github.io/web-animations/#dictdef-keyframe )
However if keyframe input contains attribute 'composite' with the value
null, the procedure for converting an
Web Animations minutes, 27 Nov 2014
Present: Doug, Dirk, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.28425
Agenda:
1. If you set the startTime on a paused player, what happens?
2. Should the player states be pause-pending and
Hi Aleksei,
Thanks for your question.
On 2014/12/03 19:38, Aleksei Semenov wrote:
According to the specification,
http://w3c.github.io/web-animations/#dom-keyframeeffect-getframes
spacing keyframes, i.e. attributes computedOffset are calculated in
method KeyframeEffect.getFrames().
Yes, but
Web Animations minutes, 18 Dec 2014
Present: Doug, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.28977
Agenda:
1. Should we call it timingFunction instead of easing?
2. How are the CSS integration specs coming along?
3. Setting
On 2014/12/17 15:09, Сергей Грехов wrote:
Hi All,
Format of scaled active time definition section is wrong. Seems there
should be ... + start_offset. Please see attached image.
Fixed in:
https://github.com/w3c/web-animations/commit/545af4361215de519460f46c7a46fa94ed2da9f6
Thanks.
Hi Aleksei,
Thanks for your mail.
On 2015/02/18 18:48, Aleksei Semenov wrote:
Hello, everyone.
The section '3.5.11. Reaching the end' describes the player behavior,
when it reaches its boundaries (either start or finish).
The section also contains a picture to demonstrate the effect of
Hi Aleksei,
On 2015/02/19 21:31, Aleksei Semenov wrote:
...
As you can see, the definition of animation node does not define any
additional
properties, that can be used to distinguish animation nodes from other
timing nodes.
Furthermore, the role (or function) of animation node is also not
Hi Sergey,
On 2015/02/19 20:17, Сергей Грехов wrote:
Hi All,
Please see the second non-normative section, containing Example 19, in
5.21. Script execution and live updates to the model
(https://w3c.github.io/web-animations/#script-execution-and-live-updates-to-the-model).
That whole section
Web Animations minutes, 14 Feb 2015
Present: Doug, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.32354
Agenda:
1. What is the set of animations returned from getAnimationPlayers()?
2. play(), pause etc. and returning Promises
3.
On 2015/03/06 19:19, Aleksei Semenov wrote:
Hello, everyone.
The specification defines two interfaces: AnimationReadonly and Animation.
First one is read-only, second is mutable.
https://w3c.github.io/web-animations/#the-animation-interfaces
The examples in the specification refer only to
On 2015/03/10 21:55, Сергей Грехов wrote:
Time fraction calculation algorithm
(http://w3c.github.io/web-animations/#calculating-the-time-fraction)
contains several steps for the case when iteration duration is zero. It's
not obvious to understand the idea of thes algorithm looking at algorithm
On 2015/04/11 15:48, Glen Huang wrote:
Hi Brian,
Thanks for the explanation.
The explanation is perfectly clear, but I'm unable to relate it to the
requirement reschedule that task to run as soon as animation is ready.
This doesn't seem to have anything to do with delaying the resolving of
the
On 2015/04/17 14:34, Glen Huang wrote:
The difficulty for a JS implementation is to make sure the times reported by
the timeline etc. match up with the current frame even when the polyfill is not
listening for frames but something else is generating them
Yes, that's the difficulty I
Hi,
If an animation is in the idle state and the current time is set, the
currently spec'ed behavior is that the animation will transition to the
running state.
This is because when the current time is set, none of the conditions
that would cause us to update the hold time are fulfilled.[1]
Web Animations minutes, 27 April 2015
Present: Doug, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.33376
Agenda:
1. Property-indexed keyframes
2. Finishing behavior
3. Publishing next WD
4. Negative infinity start delay
5. Add /
Dear all,
The editors of the Web Animations specification would like to publish
another Working Draft based on the current Editor's Draft.[1] A (rather
long) list of changes is included at the end of this mail.
We plan to publish on July 2 unless there are any objections.
Best regards,
[ Sorry for the delay here, I just discovered these notes in the
Etherpad and I don't appear to have ever sent them to the list. ]
Web Animations minutes, 28 May 2015
Present: Doug, Mike, Shane, Brian
Archived etherpad:
On 2015/06/23 8:57, Shane Stephens wrote:
An alternative proposal:
CSS animations use sequence number as priority, and are created in tree-
and list- order. CSS Animations are still prioritized absolutely above
script animations (there are two lists). Changing an animation-name
property triggers
On 2015/07/02 15:10, Shane Stephens wrote:
I guess either you're suggesting:
a) Updating animation properties triggers a global sequence number
rewrite (I hope this isn't the case), or
b) Script-animations and CSS animations share the same source of
sequence
Hi Glen,
Sorry, I'm just now catching up on your feedback.
On 2015/06/25 20:58, Glen Huang wrote:
Also curious about two things:
1. Is zero duration, forwards filled, single keyframe effect valid and
fills with the keyframe?;
```
new KeyframeEffect(el, {position: static}, {fill: forwards}) //
On 2015/06/18 16:24, Brian Birtles wrote:
Dear all,
The editors of the Web Animations specification would like to publish
another Working Draft based on the current Editor's Draft.[1] A (rather
long) list of changes is included at the end of this mail.
We plan to publish on July 2 unless
Web Animations minutes, 25 May 2015
Present: Doug, Mike, Shane, Brian
Archived etherpad:
https://web-animations.etherpad.mozilla.org/ep/pad/view/ro.92487irtSfEow/rev.37544
Agenda:
1. Name property
2. Can we drop AnimationTimeline.play?
3. AnimationTimeline.getAnimations() - sequencing
4. Use
Hi,
I'm currently speccing finish/cancel events for animations and I think
it makes sense to dispatch finish events and also update the finished
promise in a separate task.
The would mean that something like:
var anim = elem.animate({...}, 3000);
anim.currentTime = 5000;
On 2015/06/30 13:21, Brian Birtles wrote:
Hi,
I'm currently speccing finish/cancel events for animations and I think
it makes sense to dispatch finish events and also update the finished
promise in a separate task.
I was thinking of applying similar handling to the cancel event
including
Hi Amelia,
Thank you for writing this up! As a high-level comment, I like it! We've
discussed this feature a few times and there's even an issue in the spec
describing something quite similar to this.[1]
The main resistance, however, has been to the list of numbers in the
syntax. Some were
On 2015/07/09 11:30, Shane Stephens wrote:
I wonder if this proposal is a little bit odd in that we have the
following two cases:
a) var anim = new CSSAnimation(...);
anim.play();
b) elem.style.animation = ...;
var anim = elem.getAnimations()[0];
Hi,
Just following up on this thread, Shane and I discussed this a bit on
IRC yesterday and we wonder if we should push ahead with adding the
ability to tweak priorities soon-ish.
A few points we discussed:
* Priority may be confused with CSS prioritization. From here on we
will refer to
Hi Shane,
I definitely agree start-time scheduling is problematic. I was just
interested in why creation-time ordering is better, particularly as
opposed to first-transition-from-idle (let's call it FTFI).
The first two points of your mail were about the problems with TFI which
I agree are
Hi David,
On 2015/07/14 5:58, David Dailey wrote:
I'm a bit confused (still). In looking through the document, it looks
as though almost everything that looks like traditional animation
(in terms of the 15 year old thing that people used to call a W3C
Standard -- I finally understand W3C's use
Hi Kari,
On 2015/07/17 15:31, Kari Pihkala wrote:
Out of curiosity, do we even need the notion of sequence numbers? Or can
animations be regarded as belonging to a list or array structure that
can be enumerated and manipulated with familiar push/pop/insert/append
APIs? (Apologies if this has
On 2015/10/09 7:51, Shane Stephens wrote:
Any thoughts?
This seems like a really good idea.
As an extra point - we don't need to solve custom animations (onsample
effects that modify the document) until L2, so we don't need to think
about this right now - but if we said that animations
On 2015/07/01 15:59, Brian Birtles wrote:
On 2015/06/18 16:24, Brian Birtles wrote:
Dear all,
The editors of the Web Animations specification would like to publish
another Working Draft based on the current Editor's Draft.[1] A (rather
long) list of changes is included at the end of this mail
On 2015/07/09 6:50, Shane Stephens wrote:
On Fri, Jul 3, 2015 at 12:21 PM Brian Birtles bbirt...@mozilla.com
mailto:bbirt...@mozilla.com wrote:
Also, I think we need to clarify when these sequence numbers are
updated. Presumably changes to tree order prior to disassociating
On 2015/09/05 4:06, Rachel Nabors wrote:
Been seeing a need for a global playback rate for animations. Talking
with accessibility experts about older users often needing slower
animations makes me think this is something individual sites if not
browsers themselves would like to offer user
(CC-ing public-webapps and www-style since I think this API needs more
eyes on it)
Hi,
Web Animations currently has the following API[1]:
interface AnimationEffectReadOnly {
readonly attribute AnimationEffectTimingReadOnly timing;
readonly attribute ComputedTimingProperties
On Sat, Oct 3, 2015 at 1:14 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Thu, Oct 1, 2015 at 4:23 AM, Brian Birtles <bbirt...@mozilla.com> wrote:
>> I'd like to change this API, probably to one of the following (listed
>> roughly in order of preference).
Hi,
Summary:
* I think we should drop AnimationTimeline.getAnimations()
* I think we should add Document.getAnimations()
I've been working on implementing the Web Animations model in Gecko and
I've made a few observations:
1. document.timeline.getAnimations() is not really useful
If you
Hi,
(CC'ing www-style since the may be some precedent from CSSOM we can
apply here.)
Web Animations currently says that if I do the following:
var anim = elem.animate({ opacity: 0 },
{ duration: 1000, iterations: -1 });
I'll see the following:
Hi,
Web Animations defines Animatable.getAnimations() (where Animatable is
implemented by Element and a forthcoming PseudoElement interface) and I
think we've agreed to add Document.getAnimations() as well.[1]
I've found two problems with the first method which I'm going to call
--
Curator of Web Animation Weekly <http://www.webanimationweekly.com>
On Wed, Nov 25, 2015 at 6:40 PM Brian Birtles <bbirt...@mozilla.com
<mailto:bbirt...@mozilla.com>> wrote:
Hi,
Web Animations defi
place, while "equal"
doesn't but actually influence the length of each segment, so it's a bit
odd. Still, I think it's ok.
If we can't find a suitable keyword to stick into steps(), then another
option is to mint a completely separate function (e.g. stagger(),
quantize() etc.).
On M
41 matches
Mail list logo