Commits on Apr 9, 2011
  1. Merge branch 'bullet'

    mbostock committed Apr 9, 2011
  2. Separate scales per bullet.

    mbostock committed Apr 9, 2011
    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.
  3. Remove `parentData`.

    mbostock committed Apr 9, 2011
    It's equivalent to `parentNode.__data__`, so it's not needed. Technically, this
    is not backwards-compatible, but these two fields on the group object are not
    part of the public API (despite being technically accessible).
  4. Push bullet chart state into ticks element data.

    jasondavies committed Apr 9, 2011
    This means chart state (the original x-scale) is no longer bound to the
    chart instance, so a single instance can be reused on multiple elements.
Commits on Apr 8, 2011
  1. Rename var.

    mbostock committed Apr 8, 2011
  2. Add another bullet example.

    mbostock committed Apr 8, 2011
    This example shows how to preserve scales across multiples using a single chart
    instance, as opposed to bullet-multiples which uses distinct chart instances to
    supply separate scales. I still think it'd be better to use a single chart
    instance in both cases, but then I need a different place to hide the scale
  3. Merge Mike's changes.

    jasondavies committed Apr 8, 2011
  4. Merge Mike's changes.

    jasondavies committed Apr 8, 2011
    Includes hard-coded orientation for simplicity.
  5. Use separate charts for bullet-multiples.

    mbostock committed Apr 8, 2011
    This way, we get separate scales for the small multiples, which makes sense
    given our data. However, I'm not totally convinced this is the right way to
    implement separate scales, because it's a bit awkward to create separate chart
    instances that look identical. Also, it's unfortunate that the charts are
    stateful; it'd be better to somehow store the scale as data on the nodes, so
    that chart specifications could be more easily reused. Then, there might be a
    method to fix the domain rather than computing the domain per-chart.
  6. Fix bugs in remove & data.

    mbostock committed Apr 8, 2011
    The remove operator was completely broken in 1.8.6. I will add some tests to
    make sure that doesn't happen again. Also, the data operator was broken if you
    had duplicate keys in your join function; in this case, the duplicate elements
    would not always be removed.
  7. Extract title & subtitle from bullet chart.

    mbostock committed Apr 8, 2011
    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.
  8. Cache chart instances.

    jasondavies committed Apr 8, 2011
  9. Simplify bullet multiples example.

    jasondavies committed Apr 8, 2011
    Thanks Mike!
  10. Add some comments.

    jasondavies committed Apr 8, 2011
  11. Merge Mike's changes.

    jasondavies committed Apr 8, 2011
Commits on Apr 7, 2011
  1. Bullet chart transitions.

    mbostock committed Apr 7, 2011
    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
  2. Don't reselect on remove.

    mbostock committed Apr 7, 2011
    The previous behavior of selecting the parent node was extremely confusing
    because it could result in the parent node being selected multiple times (when
    removing siblings). Even worse, the child data would override the parent data!
    This changes the `remove` operator so that it matches the behavior of the W3C
    API (removeChild), returning the removed nodes.
  3. Minor optimisation.

    jasondavies committed Apr 7, 2011