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.