-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Smarter defaults for axis anchors #1200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Just encountered this again as a really peculiar failure mode for gl2d plots: gl2d_stacked_subplots does not have explicit anchors for
If you explicitly set |
I suspect actually that every time anyone has created a plot with a missing axis anchor, it has been incorrect but not noticed because the axis was in the correct location (as in the examples here), so we wouldn't need to wait for v2 to fix this. Anyway, when we do work on this, we should make sure to test constrained axes in gl2d plots per #1522 (comment) |
Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson |
We could be smarter about axis anchors for subplots, basing their default values off the traces we have.
In a new mock I made for date axes, there are 7 stacked subplots, each with one trace and its own x and y axes. All the traces have:
xaxis: 'x<n>', yaxis: 'y<n>'
and all the x axes have layout obects:
xaxis<n>: {anchor: 'y<n>'}
With smarter defaults, I would not have needed to include these x axis objects at all since
'x<n>'
is only ever used with'y<n>'
in the data. In fact, in principle my y axes should also be anchored to the corresponding x axes... I didn't do that, and it didn't matter here because all the x axes have domain[0, 1]
, but if I were to change some of these domains, then I would be in for some confusion as the y axes wouldn't move as I would expect.This would not be backward compatible, so I guess should be included in v2.0 if we do it, but I can't really think of a situation where people would be depending on the existing defaults.
The text was updated successfully, but these errors were encountered: