Use width and height attributes instead of size, for consistency with other
chart templates. (Though, note that chart templates are inconsistent with
layouts in this regard, which use a size property. But let's remain locally
consistent for now.) Default x and y properties to [0] and [1] to match the
defaults of d3.svg.area.
Add support for mode and interpolate properties. The mode can be either "offset"
or "mirror", with the default being "offset". The interpolate property is the
same as that used by d3.svg.area, and defaults to "linear".
The horizon chart now properly clips the horizon layers, such that if a horizon
chart is use within a larger SVG element, it will not extend the chart bounds.
In addition, this commit fixes a bug in how unique IDs are assigned to the clip
and area paths; it's a shame that SVG does not support a way to refer to paths
locally.
Note that because negative values are offset or mirrored, the horizon chart will
render twice as many paths (use elements) as the requested number of bands. For
example, if the default bands of 1 is used, there will be one negative band and
one positive band. In the data has no negative values, then the negative band
will be empty. Keep this in mind as it affects the layer's class attribute
(such as "q0-3" and "q2-3" for the default single-band horizon).
This applies any queued zero-delay d3.timer callbacks immediately. This is
useful in situations where zero-duration transitions are used e.g. in generic
visualisations that have a configurable transition duration.
It's often desirable to have zero-duration transitions for the initial setup
phase (so that the visualisation displays immediately). Immediate application
(rather than waiting for the setTimeout callback to fire) avoids a delay of some
milliseconds as well as an extra redraw.
See issue #48.
By default, `append` will go to the end. This could cause the center line to be
rendered on top of the box rect if whiskers were removed then re-added. By using
the `insert` operator, we can preserve the correct order.
You can now use the `text` operator on transitions, which has the same effect as
setting the text value at the start of the transition. This is nice if you have
a delayed transition, and avoids a common gotcha.
This commit also simplifies the implementation of the `text` operator using the
standard `textContent` property. This isn't supported on IE8-, but we could
potentially add support in the future using `innerText`.
Preserving object constancy across transitions is tricky! For example, what
happens if we remove the whiskers in a transition? How do we join outliers? This
commit makes a few assumptions explicit:
1. The `quartiles` function must return exactly three elements. This property
must be specified as a function.
2. The `whiskers` function must return exactly 2 elements, or null if no
whiskers are to be displayed. This property must be specified as a function.
3. The `domain` function must return exactly 2 elements, or null if the default
domain should be used. This property can be specified either as a constant or as
a function.
We could generalize this chart to support more than two whiskers, but it doesn't
seem urgent, and it would complicate the transition if the number of whiskers
changes. In a related change, the `whiskers` function does not receive a third
argument containing the quartiles; instead, this is made available by the
`quartiles` property on the values array (the first argument).
The outliers are joined using the `Number` key function. The outlier data is now
stored as indices; this allows reasonable object constancy across transitions
with outliers. Similarly, the tick labels for the quartiles are whiskers are now
separated, such that the whisker labels can be added or removed without spurious
transition.
The outliers were being incorrectly excluded when computing the quartiles. I've
also added a +/-1.5 IQR whiskers computation for the Morley-Michelson example,
so it replicates the R plot exactly.
This specifies a function that takes the sorted data array, and returns an array
of datum positions that should marked with whiskers. The default implementation
is to return `[0, length-1]` i.e. the minimum and maximum.
Data outside of the whiskers are considered outliers, and are not included in
the quartile calculation.
We were computing the tick join based on the (new) format function, but doesn't
produce the desired effect: the new format is applied on the old data. Thus, the
wrong join occurs if, say, the value 0.5 with the new format results in "0". The
correct join compares the old text content to the new format value.
Rather sharing the x-scale across bullet multiples, compute a separate scale per multiple. This
gives the user more control over the scale: by setting the range values across multiples (in data),
the user can precisely control the resulting scales. For transitions, we cache the old scale value
in a hidden __chart__ attribute. This is a bit of a hack (it might be cleaner to persist it in the
data of a child element), but it might provide a sticky way for charts to communicate with each
other in the future, say for performing transitions across chart types.
It's nice, but I think it's a bit more flexible to not have it as part of the
chart specification. This way, people can define titles however they like. It
might be nice to take a similar approach with reference ticks in the future.
We now preserve object constancy for ticks across transitions. By caching a
reference to the previous x-scale, we can initialize entering objects in the
correct location, then transition them to the new scale as they fade in. Also,
we use the `map` operator to convert the data to a standard representation that
is suitable for the bullet chart, and compute derivate data needed across
multiples.
Mike Bostock
Jason Davies