W3C home > Mailing lists > Public > www-style@w3.org > December 2011

RE: [css3-transitions] Should a transition reversal fire a transitionStart event ?

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>
Message-ID: <3C4041FF83E1E04A986B6DC50F017829033B0AFE@TK5EX14MBXC295.redmond.corp.microsoft.com>

> -----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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:47 GMT