Add a few comments.
If present, use changedTouches[0] for d3.mouse.

Normally d3.mouse(this) is equivalent to d3.touches(this)[0] because the clientX
and clientY properties of the event and the first touch are the same. However,
on touchend the touches list is empty, and the clientX and clientY are 0! So
instead it seems safer to use the position of the first changed touch for the
default location of a touch event.
Remove redundant code in d3.svg.brush.

Now that d3.mouse does the “right thing” for touch events, we don’t need code
that handles touch events specially.
Merge branch 'time-parse-zone' into 3.3.3
Merge branch 'zoom-multiple' into 3.3.3
Merge branch '3.3.3'
Fix d3.mouse touch fallback for HTML targets.
Remove dead code.

This line doesn’t appear to do anything useful, since the parent node is
now saved in the closure.  Previously, this line checked to see if
target.parentNode was null, since this would cause a crash when
computing the relative position.
Fix point-in-polygon for multiple polar rings.

Instead of detecting if any single polygon ring winds around a pole, we
consider the cumulative winding of all polygon rings together.  This is
consistent with the area calculation, which considers the cumulative
area total of all rings.

This fixes #1521: an issue with the Hammer Retroazimuthal projection,
which uses such a polygon with two rings, covering most of the globe.

In addition, drop the special handling of points at the south pole,
which might have been there to pass an incorrect test: a CCW triangle
touching the south pole, which was probably incorrectly thought to be
clockwise.  This fixes an issue with a “stripe” polygon rotated so that
a point is at the south pole, mentioned in #1453.
Use the scale as the tick key function.

Previously we were using string coercion as the key function for axis ticks.
However, when the stringified value of the tick does not fully capture the
representation (such as a date with millisecond precision, whose string form
only has second precision; fixes #1529), string coercion is insufficient.

Fortunately, there is an equivalently-simple key function for tick identity: the
scale! If the scale does not return a unique position for the given tick, then
the tick would be overlapping, so it serves perfectly as the key function.
Fix crash in ticks for empty d3.time.scale domain.

Fixes #1525. This was only an issue because the domain is extended by one
millisecond when it is empty (for an inclusive upper bound).
Merge remote-tracking branch 'origin/fix-geo-pip' into 3.3.4
Merge remote-tracking branch 'origin/fix-axis-tick-key' into 3.3.4
Merge remote-tracking branch 'origin/fix-time-degenerate-ticks' into 3.3.4
Merge branch '3.3.4'
Restrict implicit domains to explicit ranges.

When an ordinal scale’s range is explicitly defined as an array of values, we
can build the domain implicitly by progressively assigning values from the
range; this is commonly done with color palettes, for example.

However, when an ordinal scale’s range is rather implied by chopping a
continuous range into a series of points or bands, then the domain must be
specified explicitly: for the scale to be consistent, we need to know the
cardinality of the domain to compute the implied range values.

Thus, it only makes sense to extend the domain implicitly when the range is
specified explicitly. Fixes #1536 #1535.
Merge branch 'fix-implicit-ordinal-domain'
Fix clipExtent bug.

If a polygon does not intersect with the extent, but has one or more
rings inside the extent, then the extent should be checked to see
whether it is inside the polygon: if so, an additional exterior ring is
generated.

Previously, this check was only made if there were no visible rings at
all.

Fixes an issue noticed in #1453.
Simplify.
Perform winding order check on unrotated polygons.

We remove the rotation step that occurred prior to clipping, so that
clipping processes unrotated polygons.  Note that clip regions are
defined relative to the rotated globe, so clipping now needs a rotation
parameter.

Rather than moving the rotation step so it occurs after clipping, the
rotation occurs as part of clipping, using the rotation parameter to
rotate streamed points.  Alternatively, points could be clipped against
a rotated clip region, and then subsequently rotated as a separate step,
but this seems slightly less efficient.

Fixes #1453.