- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Thu, 1 Dec 2011 05:26:21 +0000
- To: Dean Jackson <dino@apple.com>
- CC: "www-style@w3.org" <www-style@w3.org>
> -----Original Message----- > From: Dean Jackson [mailto:dino@apple.com] > Sent: Wednesday, November 30, 2011 8:24 PM > To: Sylvain Galineau > Cc: www-style@w3.org > Subject: Re: [css3-transitions] Should a transition reversal fire a > transitionStart event ? > > > On 01/12/2011, at 1:01 PM, Sylvain Galineau wrote: > > >> On 30/11/2011, at 11:17 AM, Sylvain Galineau wrote: > >> > >>> Section 4. covers reversal and defines those as 'new' transitions. > >>> Is > >> that the literal intent i.e. given a start event* would a start fire > >> on each reversal ? > >> > >> Yes, that's the intent. > >> > >>> Or is this meant to describe a new phase/state of the transition? > >> > >> I think it should be as if there is a new transition from the current > >> point back to the originating point. The end event will have an > >> elapsedTime that is less than the regular transition duration. > >> > > OK so if a transition is reversed you'd see start(F),end(F),start(R), > > end(R) with the elapsed times on end(f) and start(R) reflecting their > > actual position on the overall timeline? > > I don't think you should see end(F). That should only fire when the > transition hits its end point (duration expires). Besides, in this case > you could use start(R) for the same purpose. Yes, if there is a start(R) you can deduce both the end(F) and the cancel. It does work though I'd feel better if we had the use-cases or precedents to say this is the way the event model works.
Received on Thursday, 1 December 2011 05:27:03 UTC