Repository navigation
clipped axis labels #5404
Description
In this pen: https://codepen.io/nicolaskruchten/pen/BaLGYeW?editors=0010 the right-most xaxis ticklabel should not be rendered if it's being clipped like this. Note: ticklabelmode is being set to period in the layout.template and the clipped label has no data associated with it.
Activity
archmoj commentedon Mar 10, 2021
It does not appear to be a
periodticklabelmodebug.Looking at the red plot https://rreusser.github.io/plotly-mock-viewer/#date_axes this seems to be the expected behaviour for date axes mock unless we say we should have dropped axis labels that may go outside due to the zero or little specified margin?
nicolaskruchten commentedon Mar 10, 2021
I'm not sure I understand what you're seeing in that mock... nothing is clipped for me there
nicolaskruchten commentedon Mar 10, 2021
In the mock, I can pan the X axis and never get a clipped ticklabel, but in my codepen, panning the X axis always results in clipping, on both sides actually, not just the side with the inside ticklabel on the Y axis
archmoj commentedon Mar 10, 2021
Here is a codepen.
nicolaskruchten commentedon Mar 10, 2021
OK, with this pen I can see some clipping, yes. Oh I see, in the pen I posted above it's not the edge of the plotting area that's clipping, it's the edge of the figure altogether, because the margins are so small.
nicolaskruchten commentedon Mar 10, 2021
What kind of heuristic could we build that would avoid rendering this label? In this case there is no data in 2007, so there's not really much sense in rendering this label. Resolving #5502 wouldn't get rid of this, because the 2007 gridline doesn't intersect the Y ticklabels.
Maybe we need to just not render ticklabels if they'll be clipped by the margin. @alexcjohnson thoughts?
nicolaskruchten commentedon Mar 11, 2021
This is basically the requirement, yes.
archmoj commentedon Mar 11, 2021
The it should be labeled as a feature, right?
nicolaskruchten commentedon Mar 11, 2021
I still consider the current behaviour a bug: it's ugly and should not be the default.
alexcjohnson commentedon Mar 11, 2021
Related: #3292 (nudge the first and last tick labels inward to fit within the axis span - though in this case removing these labels is better)
I'm a little worried about a blanket "remove tick labels that get clipped by the graph div boundaries" - that might catch too many things, like long category labels with automargin disabled. We would only remove those that get clipped in the axis direction, so for an x axis category labels going off the bottom would remain visible, just those that go off the right (or left) edge, most likely when the
tickanglechooses 30º.What about a new attribute
axis.ticklabeloverflowwith values'allow'(default oncategoryaxes),'remove'(default on all other axes), and perhaps eventually something like'push'to support #3292. Though there's still a question of whether overflow refers to the subplot area or the graph div - with a single subplot and no margins the two are the same. By default I think we should only remove those that overflow the div, but there are cases like closely-spaced facets where labels can overlap each other and it may be nice to avoid this.So perhaps an enum with five values:
allow(default forcategory),'remove past div'(default for others),'remove past domain', and someday'push to div'and'push to domain'. Something like that would solve this particular issue as a bug, while still allowing flexibility for the user to choose other behaviors and for us to add new behaviors later.nicolaskruchten commentedon Mar 11, 2021
That sounds great to me as a way forward, thanks for synthesizing :)
archmoj commentedon Apr 7, 2021
I think instead of passing the
divwe should consider passing therange.If one sets the left and right margins in the above graph we shouldn't render the label even if it maybe fit inside the div.
nicolaskruchten commentedon Apr 7, 2021
I think Alex's framework above leaves room for that i.e. with
'remove past domain'but I don't think we want to implement that right now and we can't use it as the new default because that's too big a change. We should implementremove past divnow though and make it the new default for v2.archmoj commentedon Apr 7, 2021
OK.
On another note, while #3292 is all about
rangenotdomainthe options could beallow,remove past div,remove past domain,remove past range,push to div,push to domain,push to range. Right?nicolaskruchten commentedon Apr 7, 2021
Per conversation just now, I think we agree that this is "domain" and "div" and not "range".
archmoj commentedon Apr 7, 2021
It looks we should not coerce
ticklabeloverflowfor inside tick labels. Correct?nicolaskruchten commentedon Apr 7, 2021
Hehe, yes :)
archmoj commentedon Apr 7, 2021
Perhaps it would be cleaner if we default it to
remove past domainfor inside tick labels, considering thepushandallowoption can be useful in some scenarios.nicolaskruchten commentedon Apr 7, 2021
Let's leave that out for now... this is for cases where the inside label is so long that it spans the whole subplot? Seems unlikely to happen very often
archmoj commentedon Apr 7, 2021
Not only that; but also it would make our supplyDefaults logic and writing the logic for tick label adjustment function simpler.
nicolaskruchten commentedon Apr 7, 2021
I thought we agreed earlier that we wouldn't have anything related to range?
archmoj commentedon Apr 7, 2021
Positive.That the domain 😀
nicolaskruchten commentedon Apr 7, 2021
Ok but for now let's just implement "remove past div" not anything domain related.
archmoj commentedon Apr 7, 2021
We already did implement 'remove past domain' functionality for inside tick labels and I am going to reuse that function for div.
nicolaskruchten commentedon Apr 7, 2021
Can I see a demo of this remove past domain in action for inside tick labels?