The -webkit- version frankly doesn't matter. It can continue to support
legacy syntax - vendors explicitly accept the risk of specifications
changing when they ship prefixed implementations. I suspect we will simply
deprecate and remove the -webkit- syntax, though (not sure about Safari).
In terms
On Wed, Feb 17, 2016 at 1:25 PM Alan Stearns wrote:
> On 2/16/16, 1:56 PM, "Tab Atkins Jr." wrote:
>
> >After some discussion with Shane, we have a new proposal:
> >
> >1. Drop fill-rule from path() and polygon(). This keeps all the shape
> >functions as just specifying the path geometry, so th
rrent proposal' as well.
Could I ask that any discussion take place on the original public-fx
thread, to keep our thoughts and ideas in one place? If necessary we can
cc: www-svg on that thread. Amelia - would you mind reposting this summary
to that thread?
Sincerely,
-Shane Stephens
On
gnostic as to whether the path() functions belong in values and units
or in shapes, and would like to defer to the CSSWG here.
Sincerely,
-Shane Stephens
On Thu, Feb 4, 2016 at 9:32 AM Amelia Bellamy-Royds <
amelia.bellamy.ro...@gmail.com> wrote:
> I don't think there is a conflict. There
Hi list,
Cameron pointed out today that the path() function in motion-1 takes a fill
rule. It looks like dschulze added this late in 2014 so that other
specifications (some of which need a fill rule) could reference the path
syntax too.
Cameron pointed this out because he wanted to reference this
> 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 without a target element
belong to the document
Hi list,
When interpolating between rotations with different axis alignment, we
always fall back on matrix decomposition.
However, if one of the angles is 0, then the resulting behavior is that the
rotation axis snaps immediately to the other axis. So for example, if I
transition
transform: rotat
On 2015/07/15 8:37, Shane Stephens wrote:
> > (3) It is idiomatic to create animation resources separately from their
> > scheduling. We've already seen a desire to do things like this with
> > declarative animation and triggers, or with time sheets.
>
> It seems
Replying in this thread to maintain the context.
I think that would be good. I'm afraid I can't quite remember why
> creation ordering is better or why this proposal is better. I'm not
> opposed to it but I'd like to give others a chance to check it over too.
>
> Would you mind writing quick summa
> 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];
> elem.style.animation = "";
> anim.play();
>
> In (a), the p
On Fri, Jul 3, 2015 at 12:21 PM Brian Birtles wrote:
> 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'
Hi list,
Here's how we currently define quaternion SLERPing during interpolation:
http://dev.w3.org/csswg/css-transforms/#interpolation-of-decomposed-3d-matrix-values
When quatA = [0, 1, 0, 0] and quatB = [0, -1, 0, 0], this has the
unfortunate side effect of setting product to -1, which means th
>
> 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 numbers but when we come to prioritize animations we
>
SGTM, but should we go with 'id' instead of 'name' (which I think is what
we ended up deciding was best in the May 25th f2f)?
Cheers,
-Shane
On Wed, Jul 1, 2015 at 12:07 PM Brian Birtles wrote:
> Hi,
>
> Currently, Web Animations defines a 'name' attribute on
> KeyframeEffectReadOnly. I thi
On Tue, Jun 23, 2015 at 11:04 AM Brian Birtles wrote:
> On 2015/06/22 16: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 absolu
n, Jun 21, 2015 at 10:24 PM, Brian Birtles
> wrote:
> > On 2015/06/22 14:14, Brian Birtles wrote:
> >> On 2015/06/22 13:10, Shane Stephens wrote:
> >>> One concern I have is that currently text order (or creation order) is
> >>> inviolate which makes
On Mon, Jun 22, 2015 at 8:42 PM Kari Pihkala wrote:
> 2015-06-22 9:47 GMT+03:00 Shane Stephens :
> > I think this is so that you *can* move the motion path if you need to. If
> > motion came first then you'd need to resort to nested divs or similar.
>
> I think the tr
>
In general - yeah, though some of them may be difficult. Another question,
though, is 'does this hook fit with the realities of animation' - sadly the
answer here is no, because it's impossible for us to give you an event
callback in which it's safe to modify visual state.
Cheer
the topic
at hand, please start a new thread and ask it there.
Sincerely,
-Shane Stephens
>
> You say:
>
>
> "(But there's nothing wrong with putting strings like that in CSS; I'm
> unsure why you think there's a meaningful difference between d="
On Wed, Jun 17, 2015 at 6:53 AM Amelia Bellamy-Royds <
amelia.bellamy.ro...@gmail.com> wrote:
> Some thoughts on the proposals & points raised by both Shane and Dirk:
>
>- Most existing animation libraries have two parallel methods, one for
>style properties and one for attributes. There
On Mon, Jun 22, 2015 at 4:20 PM Kari Pihkala wrote:
> 2015-06-22 7:27 GMT+03:00 Amelia Bellamy-Royds <
> amelia.bellamy.ro...@gmail.com>:
> > Keywords also complicate the animatability of the property. And since
> this
> > property is all about animation, that should be a significant factor.
>
>
s.).
>
One major issue is that you can't represent intermediate states without
losing information. At the moment in Chrome, animations from
to/from flip at 50%.
Cheers,
-Shane
>
> Best,
> ABR
>
> On 21 June 2015 at 21:32, Shane Stephens wrote:
>
>> Hi list,
On Mon, Jun 1, 2015 at 2:39 PM Brian Birtles wrote:
> Hi,
>
> I'm trying to nail down the ordering of animations so I can implement it
> in Firefox. I wrote up an outline of this on Github[1] and went over it
> with Shane, Doug and Mike last week who agreed it seems reasonable.[2]
>
> Coming to i
Hi list,
Issue 5 of the motion-path specification deals with whether there needs to
be an origin specified for element impacted by motion paths. Specifically:
"Do we need to specify an origin of the element in motion so that it can be
positioned accordingly before the motion? Something like motio
Hi list,
Issue 2 of the motion-path specification requests more natural names for
‘auto’ and ‘reverse’. This is in the context of the motion-rotation
property: http://dev.w3.org/fxtf/motion-1/#motion-rotation.
A specification of ‘motion-rotation: auto’ causes the targeted element to
rotate so tha
On Tue, Jun 16, 2015 at 10:09 PM Dirk Schulze wrote:
> On Jun 16, 2015, at 1:45 PM, Shane Stephens wrote:
>
>
>
> On Tue, Jun 16, 2015 at 9:24 PM Dirk Schulze wrote:
>
>> On Jun 16, 2015, at 9:35 AM, Shane Stephens wrote:
>>
>>
>>
>> On
On Tue, Jun 16, 2015 at 9:24 PM Dirk Schulze wrote:
> On Jun 16, 2015, at 9:35 AM, Shane Stephens wrote:
>
>
>
> On Tue, Jun 16, 2015 at 4:46 PM Dirk Schulze wrote:
>
>> On Jun 16, 2015, at 7:16 AM, Shane Stephens wrote:
>>
>> Shall WebAnimation
On Tue, Jun 16, 2015 at 4:46 PM Dirk Schulze wrote:
> On Jun 16, 2015, at 7:16 AM, Shane Stephens wrote:
>
> Shall WebAnimation also animate HTML attributes at some point?
>
>
> I don't know. We've talked in the past about animating class. I'd also
&g
>
> Shall WebAnimation also animate HTML attributes at some point?
I don't know. We've talked in the past about animating class. I'd also like
to be able to animate scroll offsets at some point.
> If yes, shall these attributes be “html” prefixed as well?
Yes. I think that would make sense.
Hi list,
One of the goals of Web Animations is to enable animation of any SVG
attribute (whether presentation or otherwise). For many attributes this
will simply involve a 50% flip, but there are attributes (e.g. 'd') that
aren't presentation attributes but nevertheless have smooth interpolation
b
Hi Glen,
On Wed, May 27, 2015 at 5:09 PM Glen Huang wrote:
> Hi, I recently tried to manage very complex animation, and realized I need
> this feature:
>
> When animations fire ready and finish events, they first bubble into to
> the associated effects, if effects have nesting children, recurs
I've updated the ED to reflect this change.
Cheers,
-Shane
On Fri, Apr 17, 2015 at 9:15 PM Dirk Schulze wrote:
>
> > On Apr 16, 2015, at 10:42 PM, Tab Atkins Jr.
> wrote:
> >
> > On Thu, Apr 16, 2015 at 12:33 AM, Erik Dahlström wrote:
> >> Hi,
> >>
> >> forwarding on behalf of Eric Willig
>
> First, recall the states of an Animation which we can simplify to the
> following three:
>
> idle = no current time (*may* have a start time)
> paused = has current time but no start time
> running = has current time and start time
>
> 'finished' is (currently) just a variation on '
>
>
> 2. Animations are actually groups:
>
> The truth is I don’t really understand all of the issues raised by Brian
> and Shane in this thread:
>
> https://lists.w3.org/Archives/Public/public-fx/2015JanMar/0106.html
>
>
> But I really, REALLY, want a simple, high performance, single property
Hi Glen,
The current two-tier approach to easings exists because:
(1) CSS behaves as you've proposed, but with disjoint: true *always* set
(2) This behavior is generally less useful than easings that operate over
the whole animation.
We'd generally recommend not specifying per-keyframe easings, w
>
> Seeing as this is an existing limitation in the spec and we agree on the
> direction we want to go, I don't think it should block the proposed API
> changes so I've gone ahead and merged them now.
>
Well, no - there used to be a constructor and now it's gone. At least add
an issue or something
On Thu, Mar 12, 2015 at 12:38 PM Brian Birtles wrote:
> On 2015/03/12 10:10, Shane Stephens wrote:
> >
> > Unfortunately I was unable to make a shared keyframe list since as
> was
> > discussed at one stage.[3] This is because keyframe lists return
> their
&
sors on a
KeyframeList should return the unmodified inputs.
It's fine to keep a getFrames method on the KeyframeEffect object for
accessing the computed result (in a place where the target is known) -
although I think this could be deferred to a later level as we don't have
currently have strong use cases for it.
Sincerely,
-Shane Stephens
Hi Sergey,
We've considered iteration delay in the past. Unfortunately it's
complicated by the question of fill: should iteration delay be a fill
forwards region, a fill backwards region, or fill none? Or should there be
a separate iteration fill?
Cheers,
-Shane
On Tue, Mar 3, 2015 at 4:47 P
Hi Glen,
There are some significant problems caused by providing events inside
animation, mainly around the interplay between discrete sampling (animation
frames) and continuous timing functions. Examples:
* when a timing function in a group modifies the final end time of a child
animation, should
ec, but decided to
defer to a later level so that we could iterate faster.
Cheers,
-Shane
>
> On 04/02/2015 00:35, Shane Stephens wrote:
> > Hi Jonathan,
> >
> > Thanks for your feedback.
> >
> > Would 'animation' still be appropriate if players
Hi Jonathan,
Thanks for your feedback.
Would 'animation' still be appropriate if players can target non-animation
content (e.g. video or audio) in the future?
Thanks,
-Shane
On Wed Feb 04 2015 at 11:28:56 AM Jonathan Watt wrote:
> Can the AnimationPlayer.source property *please* be rename
The computed timing should return the values used for timing calculations.
We should clarify this in the specification.
Cheers,
-Shane
On Mon Dec 15 2014 at 6:05:13 PM "Сергей Грехов" wrote:
> Hi All,
>
> It's unclear from the spec what values should return
> computedTiming.iterationStart a
More powerful easings are something I think we definitely need in the API,
and something we've discussed before during specification meetings.
With specific regard to easings as javaScript functions: currently there
are performance reasons why we don't want to support this. In particular,
having j
he elements is not in sync. With the raf
> version this effect is not seen. I will try to isolate it tomorrow but I
> may have to move on to other things. It might end up being a bug in my code
> but it looks like a easing issue from my experience.
>
> On Tue, Nov 18, 2014
Hi Jonathan,
Chrome 39 implements easing. What was the problem you were seeing?
Thanks,
-Shane
On Wed Nov 19 2014 at 11:28:26 AM Jonathan Moore wrote:
> I now have a mostly working ( chome 39 ) version of my lib using web
> animations. You can see a demo at:
>
> http://0x.bitbucket.o
This .. also seems like a bug. currentTime doesn't progress between frames.
We'll look into it.
Cheers,
-Shane
On Wed Nov 19 2014 at 11:13:54 AM Jonathan Moore wrote:
> On Tue, Nov 18, 2014 at 3:59 PM, Shane Stephens wrote:
>
>>
>> In contrast, when
ore wrote:
>
> On Tue, Nov 18, 2014 at 12:39 PM, Shane Stephens wrote:
>
>> I think this issue points to a bug in the Chrome implementation. Even
>> though cancel is asynchronous, from the perspective of the main thread its
>> effect on style should be immediat
Hi Sergey,
Yes, this is a good point. I think that we will need to move the wording in
the last part of the algorithm ('if the transformed time is unresolved,
return an unresolved time value') to the top as a first test. I'll update
the spec.
Cheers,
-Shane
On Tue Nov 18 2014 at 8:25:36 PM "
This isn't a timing issue, it's a consequence of cancel() having
asynchronous effect. Inserting a new element hasn't actually updated the
animation style, even though it does force a style recalc - it actually
takes a rAF for the animation's effect to stop applying.
I think this issue points to a
50 matches
Mail list logo
