Accepted answer

That block is written in d3 v4. It looks like the v3 transition.each has been renamed transition.on (which makes more sense). That said start has always been an event-type for a transition:

If type is specified, adds a listener for transition events, supporting "start", "end" and "interrupt" events. The listener will be invoked for each individual element in the transition.

The start event is invoked during the first asynchronous callback (tick) of the transition, before any tweens are invoked. For transitions with zero delay, this is typically about 17ms after the transition is scheduled. State events are useful for triggering instantaneous changes to each element, such as changing attributes that cannot be interpolated.

To answer you specific question (my bolding above) "or is it for when the transition begins after the delay period" - yes.


I've been poking around trying to figure this out. "start" is not a normal DOM event and is not one of the events supplied by D3. After doing some research, here's what I've come to find out:

"Transitions are a limited form of key frame animation with only two key frames: start and end"

"The start event is then dispatched, and the transition initializes its tweens, which may involve retrieving starting values from the DOM and constructing interpolators."


(that's linked to directly from the d3-transition repo @ see "working with transitions" link).

I believe that the D3-transition library being used in the example implicitly uses the same - that is, the transitions have two key frames. The "start" "event" actually represents the first key frame. In fact, there's a slight delay when the transition begins so it makes sense that one would wait until the keyframe "started".

Related Query