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.
The axis component no longer uses a transition for the text elements' dy and
text-anchor attributes. This makes it easier to style the labels using post-
selection, since the transition will not override custom attribute values.
Prior to this change, transitions used transition.each internally, which had the
unexpected side-effect of enabling transitions on d3.transition(selection) when
called from within a tween function. This would only occur on the first
invocation of the tween function when the elapsed time between the transition
creation and the transition start was greater than the transition delay;
however, this is fairly common as the default delay for transitions is zero.
This bug caused unexpected behavior if you tried to redraw an axis within a
custom tween function: in some cases, the synchronous redraw of the axis would
compete with a concurrent transition, causing unexpected behavior. By avoiding
the use of transition.each internally, the user now controls when automatic
transitions are enabled.
Previously, the log scale's tick format would hide all labels when there was not
enough room to display the requested number of ticks; now it at least displays
the power-of-ten labels. Fixes#655.
The transition-test-text callback was failing to fire when using the
latest Node.js master (82bcdbb8aaa4cf58917dc8d3fd4fcfc272512a2c). This
was most likely due to these tests being run in a different order due to
a different object enumeration order.
In future we may want to generate some kind of loop, but it's not clear
what orientation such a loop should have, so perhaps a "non-line" like
this is better as a default.
If the error flag is set, the response attribute [1] should be the empty
string or null. So even if a request fails and the response has been
partially loaded, this logic should still work.
This check will fail for local requests where the response entity body
is the empty string, but I don't think it's possible to detect this
situation in current browser implementations. jQuery has the same issue,
for example.
[1]: http://www.w3.org/TR/XMLHttpRequest/#the-response-attribute
The test for local URI is based on jQuery's. Although Chrome has strict
permissions, other browsers allow local URIs to be retrieved as long as
the same-domain policy is respected e.g. Safari.
We also check for a cross-domain request as req.status === 0 means
failure in this case.