axis mark

[mbostock]

This implements axes as a proper mark, allowing a high degree of custom styling, even data-driven.

• Channels (e.g., varying color based on value)
• Grid
• Left-oriented y-axis
• Bottom-oriented x-axis
• Right-oriented y-axis
• Top-oriented x-axis
• Smarter default ticks (port autoAxisTicks)
• Smarter default tick format
• Tick rotate equivalent
• Axis insets
• Axis dx and dy
• Facet axes 😬
• A variant of facetAnchor that allows strict placement on the sides (for facet axes)
• Remove Plot’s built-in axis rendering and instead automatically add axis marks as needed
• Axis line option
• y-axis labels
• x-axis labels
• fx-axis labels
• fy-axis labels
• Implement labelAnchor option
• Implement labelOffset option
• Implement tickSpacing option (80px / 35px default)
• Fix label position for ordinal scales
• Fix label arrow based on chosen label anchor
• Fix facet axis label positions
• Fix named time intervals (polylinear test)
• Don’t allow tickSize to be specified as a function
• Implement the both axis option
• Tests
• Investigate missing x-axis in “yearly requests” tests
• Investigate broken metroUnemploymentRidgeline
• Investigate downloadsOrdinal test
• Investigate penguinDodgeHexbin test
• Investigate projectionHeightGeometry test
• Shorthand x and y option for grid marks
• Documentation

Nice to haves:

• Don’t duplicate axis label when there are multiple axes?
• Pass through the lineWidth option to wrap tick labels?
• Shorthand for conditional remove-if-the-same-as-previous multi-line tick time formats?
• Allow the axis tick shape vector option (and others) to be overridden?
• A lineOffset option for translating tick text relative to the tick anchor?

Fixes #6.
Fixes #7.
Fixes #114 (#385).
Fixes #148.
Fixes #210.
Fixes #375.
Fixes #460.
Fixes #464.
Fixes #522.
Fixes #609.
Fixes #612.
Fixes #631.
Fixes #926.
Fixes #976.
Fixes #985.
Fixes #987.
Fixes #992.
Fixes #1000.
Fixes #1198.
Fixes #1199.

[mbostock]

Since the axes are driven by data, you can now do neat stuff like vary the x-position of the y-axis:

Plot.gridY({x: (y) => AAPL.find((d) => d.Close >= y)?.Date, insetLeft: -10}),
Plot.axisY({x: (y) => AAPL.find((d) => d.Close >= y)?.Date, insetLeft: -10})

[mbostock]

ggplot2 theme?

Plot.frame({fill: "#eaeaea"}),
Plot.gridY({tickSpacing: 35, stroke: "#fff", strokeOpacity: 1, strokeWidth: 0.5}),
Plot.gridY({tickSpacing: 70, stroke: "#fff", strokeOpacity: 1}),
Plot.axisY({tickSpacing: 70}),
Plot.gridX({tickSpacing: 40, stroke: "#fff", strokeOpacity: 1, strokeWidth: 0.5}),
Plot.gridX({tickSpacing: 80, stroke: "#fff", strokeOpacity: 1}),
Plot.axisX({tickSpacing: 80}),

[mbostock]

We’ll be able to fix #522 with this, too!

[mbostock]

I think axis = "both" should only draw one axis label? It’s nice to have the ticks drawn twice but I think you often don’t want a second axis label. (And you can always do that by adding an axis mark yourself, so it’s nice to favor the common one with axis = "both".)

[Fil]

An open question: do we need to support data in the axisX(data, options) syntax, since the tick values can be passed as options.ticks, with—I think?—no loss of generality.

[mbostock]

An open question: do we need to support data in the axisX(data, options) syntax

I chose not to do this. Here are my reasons:

1. When data is specified up-front, we can compute channels the normal way rather than deferring it to the initializer. This means that specifying the data up-front has different behavior than specifying an array of ticks: in the former case, it can extend the scale domain, whereas in the latter, it can’t (because initializers aren’t allowed to affect the behavior of position scales). I realized I broke this along the way, but I’ve fixed it in 61e1145 and added a test.

Plot.plot({
  marks: [
    Plot.axisY(d3.ticks(0, 200, 10), {anchor: "left"}),
    Plot.lineY(AAPL, {x: "Date", y: "Close"})
  ]
})

2. Philosophically, I think it’s desirable to support the same syntax with axis marks that we do with other marks, especially when “under the hood” the data associated with an axis mark is this array of tick values. Yes, axis marks are special in that typically the tick values depend on the scale domains, and hence cannot be known until after the other marks are initialized; and because channels depend on data, that means typically all of an axis mark’s channels need to be deferred to an initializer too. But per (1) it’s nice that if the data is specified up-front, we can have the axis mark follow the same code path as a normal mark.*

*The fontVariant and tickFormat also depend on the scale, and so also need to be deferred to the initializer. And likewise axis label orientation. But we can at least make the axis mark behave as much like a normal mark as possible.

[mbostock]

In a case like this

Plot.plot({
  y: {
    grid: true
  },
  marks: [
    Plot.axisY({anchor: "left"}),
    Plot.lineY(AAPL, {x: "Date", y: "Close"})
  ]
})

should we still draw implicit the y-axis grid even though there’s an explicit y-axis? I kind of think that yes, we should. Though that would also mean that the implicit y-axis grid would use the default ticks, which could be different than those chosen by the explicit y-axis. That seems fine, though.

[Fil]

Thanks for 61e1145 which clarifies the issue.

We still need to iterate a bit on the documentation, but I'm happy with everything

[mbostock]

Oh, there was another idea I had for shorthand: if the grid option is a number or an interval (or an interval name), it gets promoted to the ticks option of the grid mark; if the grid option is a color, it gets promoted to the stroke option of the grid mark. Then you can say grid: 20 for more grid lines, or grid: "red" for a red grid, etc. Not really needed since you can do the same thing with an explicit mark but it’s always fun to have extra shorthand…

[mbostock]

This seems like a bug: when there’s an explicit x-axis, the default anchor of the implicit fx-axis changes to bottom instead of top, resulting in the two axes overlapping. I’m guessing that the fx-axis should always default to a top anchor.

Plot.plot({
  facet: {marginRight: 80},
  marks: [
    Plot.frame(),
    Plot.dot(penguins, {x: "culmen_length_mm", y: "culmen_depth_mm", fx: "sex", fy: "species"}),
    Plot.axisX({color: "red"})
  ]
})

[Fil]

Should Plot.axisX be wrapped with Plot.marks? Currently we have to write

Plot.marks(Plot.axisX(d3.ticks(0, 1, 10), { stroke: "red" })).plot(…)

it could be simpler to manipulate as:

Plot.axisX(d3.ticks(0, 1, 10), { stroke: "red" }).plot(…)

[mbostock]

Yes, it should use Plot.marks. That’s an oversight on my part.

[yurivish]

tiny note: i just noticed that the README says "The mark.facetAnchor option controls TK. " which was introduced in this PR. I'd fix it myself but am not sure what it should say...

[mbostock]

Yes, the documentation is still being written. Thanks!