It is now possible to reselect elements with scheduled transitions and redefine
associated tweens; this enables "post-selection" to customize the behavior of
reusable components undergoing transitions, such as an axis. This commit also
makes it much easier to sequence transitions.
Previously, a transition's tweens were stored privately by the transition and
could only be accessed through the transition. This made it impossible to modify
transitions created by components: the transition is not accessible externally,
and cannot be reselected from the document. Consider the following snippet:
g.select(".x.axis")
.call(xAxis)
.selectAll("text")
.attr("dy", null);
If `g` is a selection, then this code alters the appearance of the axis as
expected. However, if `g` is a transition, then transition.selectAll creates a
new concurrent transition, and now multiple tweens compete to set the "dy"
attribute. Oy!
Under the new design, an element's scheduled tweens are stored semi-privately on
the node (in the existing node.__transition__). Transition parameters can thus
be reselected and modified by transitions that share the same id. If you now
reselect a transitioning element, you modify the transition rather creating a
competing transition; this should be less surprising and allow greater control.
As a side-effect of this change, it is no longer possible to schedule concurrent
transitions on the same element, even with the same id: only one transition may
be active on a given element at any time. (Note that you can still schedule
multiple future transitions on the same element, and concurrent transitions on
different elements.) For example, you could previously schedule overlapping
transitions with different easing functions, delays or durations, provided you
were careful to avoid conflict. This seems like a relatively obscure use-case
compared to modifying a transition, so I believe this is a reasonable change.
This commit also changes transition.transition, such that the returned
transition starts at the end of the originating transition, rather than
overlapping. This makes it much easier to schedule sequenced transitions without
the complexity of transition.each("end") and d3.select(this).
Also, transitions are now simply arrays of nodes, consistent with selections!
Rather than adopting CSS’s elaborate rules for detecting when the start and end
transform are the same type as using piecewise (i.e., string-based)
interpolation, we always use the consolidated transform transition. If you want
to use string-based interpolation, simply specify d3.interpolateString as the
interpolator. Fixes#746.
The shortest-path interpolation for HSL was causing all the bars to be the same
color. Switching to string-interpolation preserves the original behavior.
If the transform transition isn't the same type, then we can use the shortest-
path for rotate transitions. But, if the transforms are the same type, then we
should use the simpler string interpolation without the shortest-path.
For consistency with CSS3 [1], a null "from" or "to" transform list is
replaced by an identity function list whose types match those of the
non-null transform list.
[1]: http://www.w3.org/TR/css3-transforms/#animation
For consistency with CSS3's 2D transforms, two transforms with the same
number of transform functions and corresponding functions of the same
type are treated differently: each transform function is interpolated in
isolation.
This allows us to interpolate many transforms that contain constant
functions in a more useful way, e.g.
"rotate(<variable>)translate(<constant>)"
The variable rotation angle would now be linearly interpolated on its
own, keeping the constant translation vector constant.
The previous method of subtracting slightly from the radius introduces
distortion where smaller circles are disproportionately reduced. For example,
subtracting 1px from the radius scales a circle of radius 5px by 0.64x, while a
circle of radius 50px is only reduced by 0.96x.
By incorporating padding into the layout algorithm, the leaf circles’ area is
still proportional to the associated value. Due to the scale-independent nature
of the layout, the specified padding value is only approximate.
Mike Bostock
Jason Davies
Kristofer Monisit