We still weren't sorting subgroups correctly. Also, we now sort chords by their average value, rather than the source value, which works well with one-sided chords (where either the source or target value is zero).
Due to the ordering in which the prototypes are defined, it was still undefined! Also, the empty method depends on the node method being defined. Added a test.
It was previously possible for small differences in the reference time for subtransitions. This could lead to tearing with expensive transitions, as some transitions would have slightly different reference times than the others. This is fixed by passing the reference time along explicitly when deriving a new transition, either by the transition or selection operators.
I ran the tests on the newly minified files too, for good measure, and everything passed.
We weren't computing the day-of-year number correctly, which affected both day number and week number directives (%j, %U, and %W).
The d3.time.format.iso is designed to be compatible with the default JSON serialization of dates, which includes milliseconds. So, d3.time.format now supports the %L directive for formatting and parsing milliseconds. This commit also changes d3.time.format.iso to use native ISO date methods, if available.
Also, expose d3.formatPrefix so that it's easier for callers to create a formatter for a specific prefix (such as using the "G" prefix for all ticks).
This simplifies the implementation and fixes a few bugs. The si prefix format ("s") now supports variable precision; in fact, you are strongly recommended to specify a precision, such as ".3s".
You can now change the orientation and the axis will redraw correctly. When an axis is applied by a transition, the subtransitions will properly inherit the transition id, allowing transitions on reselected elements to continue.
This arranges them first by the type of polygon we're testing, then the operations. I've added tests for clockwise polygons too, for good measure.
d3.geom.polygon(…).area() assumes screen pixel coordinates with (0, 0) at the top left, and y increasing going downwards. This results in a positive area for counterclockwise coordinates. Howver, the default centroid calculation was assuming "usual" Cartesian coordinates with y increasing going upwards, hence the centroid coordinates were incorrectly multiplied by -1. This fix won't affect d3.geo.path(…).centroid() as it passes a constant to d3.geom.centroid.
Fix tests in Linux.
This occurs on Linux, where the directory listing order is different from OS X and so other tests leave data bound to the "body" element. This data is then propagated when new elements are appended, and thus mess up some of the tests!