60px default y-axis margin

[mbostock]

Fixes #1451.

TODO: Investigate whether we can further increase the default margin to 80px in the case that an ordinal scale is used (in which case, the ticks tend to be longer) or a center labelAnchor is used (which is also the default for ordinal scales, and shares space with the tick labels). Both of these are tricky to do because the scale type is not known at the time the axis mark is constructed, and initializers are not allowed to affect position scales. We would need some sort of new hint or hook that would allow the axis mark to peek ahead at the scale type and adjust the default margin accordingly.

[mbostock]

I also don’t like that there’s too much left margin now in many of the examples. It would be nice to have a smarter heuristic. I don’t think it needs to be as precise as proper text metrics, but maybe something that can choose between a “small”, “medium”, and “large” default margin?

[Fil]

I want to explore an alternative where the axis mark would set the value of marginLeft (etc.) not to a number, but to a special value (Symbol["autoMargin"] or just a string, if we want to keep this usable from outside); the actual numeric value of that special autoMargin value would be computed in createDimensions—where the scales’ types and domains are already materialized. (#1722)

[mbostock]

Maybe we could compute the labels for the y-axis, and use their length (simple text metrics) to estimate whether a small or large left/right margin is needed. And then we move on to do the same for the x-axis. This would also be useful to estimate a good default tickSpacing for the x-axis: if we have shorter or longer labels, we can adjust the default accordingly. The sparseCell test with ordinal axes is a good example of where we could use a small tickSpacing than the default (at least for x; the y default probably shouldn’t change).

[mbostock]

Closing in favor of #1722.