[css3-transitions] 'transitionstart' and 'transitioncancel' events

Hello,

I would like to propose that support for 'transitionstart' and
'transitioncancel' event types be added to the CSS Transitions spec.

>From searching the archives, there has not been very much discussion on
www-style regarding adding other transition event types.  The only threads
that I could find are:
- http://lists.w3.org/Archives/Public/www-style/2009Apr/0413.html
- http://lists.w3.org/Archives/Public/www-style/2010Jan/0129.html
- http://lists.w3.org/Archives/Public/www-style/2010Jun/0317.html
- http://lists.w3.org/Archives/Public/www-style/2011Nov/0764.html

Currently only Internet Explorer 10+ supports a 'transitionstart' event:
http://msdn.microsoft.com/en-us/library/ie/dn632683.aspx

The use case that I have in mind is:  I want to extend an existing
JavaScript UI framework with a carousel-style container widget that
supports transitioning between an arbitrary number of pages (other
widgets).  I also want to be able to support calling a callback whenever a
transition between pages finishes or is canceled.  Because the exact number
of pages is not known, I cannot use CSS animations ("Animations are similar
to transitions ... The principal difference is that while transitions
trigger implicitly when property values change, animations are explicitly
executed when the animation properties are applied. Because of this,
animations require explicit values for the properties being animated.").

This JavaScript framework that I am working with supports the ability to
add widgets to other widgets, hide widgets (and their children), and other
operations where the DOM elements comprising the carousel widget would
either be made invisible (via display:none), detached from the document, or
added as child nodes to other elements.  All of these DOM manipulations can
result in an active transition being canceled (or not starting).  From some
simple tests:
- Firefox ESR 24.5.0 will complete a transition (and fire 'transitionend')
if the element is hidden via visibility:hidden or display:none and then
re-shown, but not if the element is added to a different element.
- Chrome 34.0.1847.131 will complete a transition (and fire
'transitionend') if the element is hidden via visibility:hidden and then
re-shown, or if hidden via display:none and then re-shown not more than
~7ms later, but not if the element is added to a different element.
- IE 11 will complete a transition (and fire 'transitionend') if the
element is hidden via visibility:hidden and then re-shown, but not if
display:none is applied to the element at any time (even if immediately
reset to "") or if the element is added to a different element.

Aside from framework-level operations, there is also the possibility of
unintentional misuse of the API, such as calling the "scrollToPage()"
method two or more times in the same timer, specifying different pages for
each call.  For example, if `scrollToPage(3, callback1)' were called, and
then `scrollToPage(8, callback2)' in the same thread of execution, then the
transition for the `scrollToPage(3, callback1)' call would not start, and
only the transition for the `scrollToPage(3, callback1)' call would run
(assuming nothing else cancels it).

In my case, I essentially want to be able to implement a promise so that if
a scrollToPage() transition is canceled or won't start, then an onError
callback will be called, and if the scrollToPage() transition finishes, an
onComplete callback will be called.  This is similar to the APIs in the
Windows 8 Animation Library:
http://msdn.microsoft.com/en-us/library/windows/apps/hh465165.aspx
In the case where a callback object is passed to the scrollToPage() method,
I want to call the supplied callback in both cases.

I have written some code using getComputedStyle() that I am pretty sure
works in detecting the "unintentional misuse" cases when a transition
either won't start or will be canceled.  However, the cases that are
troublesome are the cases where the transition is canceled by some DOM
manipulation.

When a widget is shown or hidden, then the JS framework that I am using
sends a notification to the shown or hidden widget and all of its
descendants.  However, the framework does not fire such recursive
notification for other operations that result in DOM modifications that
cancel the transition.

I could, of course, modify the JS framework to recurse through all
descendants whenever any of these types of operations occur, but this is
very inefficient.  It would be immensely useful if a 'transitioncancel'
event would be fired on the element itself when the transition is canceled,
particularly because the user agent knows all of the rules for when a
transition is canceled.

As for the 'transitionstart' event, I propose adding this event type so
that the CSS Transitions spec can specify that a 'transitioncancel' event
would only be fired if the transition is canceled after the transition has
started (a 'transitionstart' event has fired).  This fixes a point of
confusion regarding the notion of canceling something that hasn't even
started.

Does this sound like an interesting proposal?