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.
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.
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.
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!
Previously, these would work by coercing the input color to a string and then
parsing it. This is slow, but more importantly, this is a lossy process for HSL
colors due to the conversion to hexadecimal RGB format. This commit detects
instances of d3_Rgb and d3_Hsl on input and copies them efficiently.
When computing the reversed baseline, we need to switch between step-before and
step-after, since the points are in reverse order. Otherwise, we're effectively
filling the gap between step-before and step-after.
Using the comma operator isn't so bad, and I added it to removeAttribute
for good measure in case there's an implementation out there that
returns something.
Quote from NEWS file:
In previous versions of make it was acceptable to list one or more explicit
targets followed by one or more pattern targets in the same rule and it
worked "as expected". However, this was not documented as acceptable and if
you listed any explicit targets AFTER the pattern targets, the entire rule
would be mis-parsed. This release removes this ability completely: make
will generate an error message if you mix explicit and pattern targets in
the same rule.
Jason Davies
Mike Bostock
Lars Kotthoff