clipped axis labels

[nicolaskruchten]

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.

[archmoj]

It does not appear to be a period ticklabelmode bug.
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]

I'm not sure I understand what you're seeing in that mock... nothing is clipped for me there

[nicolaskruchten]

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]

Here is a codepen.

[nicolaskruchten]

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]

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]

Maybe we need to just not render ticklabels if they'll be clipped by the margin

This is basically the requirement, yes.

[archmoj]

The it should be labeled as a feature, right?

[nicolaskruchten]

I still consider the current behaviour a bug: it's ugly and should not be the default.

[alexcjohnson]

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 tickangle chooses 30º.

What about a new attribute axis.ticklabeloverflow with values 'allow' (default on category axes), '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 for category), '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]

That sounds great to me as a way forward, thanks for synthesizing :)

[archmoj]

I think instead of passing the div we should consider passing the range.
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]

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 implement remove past div now though and make it the new default for v2.

[archmoj]

OK.
On another note, while #3292 is all about range not domain the options could be
allow, remove past div, remove past domain, remove past range, push to div, push to domain, push to range. Right?

[nicolaskruchten]

Per conversation just now, I think we agree that this is "domain" and "div" and not "range".

[archmoj]

It looks we should not coerce ticklabeloverflow for inside tick labels. Correct?

[nicolaskruchten]

Hehe, yes :)

[archmoj]

Perhaps it would be cleaner if we default it to remove past domain for inside tick labels, considering the push and allow option can be useful in some scenarios.

[nicolaskruchten]

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]

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

Not only that; but also it would make our supplyDefaults logic and writing the logic for tick label adjustment function simpler.

[nicolaskruchten]

I thought we agreed earlier that we wouldn't have anything related to range?

[archmoj]

I thought we agreed earlier that we wouldn't have anything related to range?

Positive.That the domain 😀

[nicolaskruchten]

Ok but for now let's just implement "remove past div" not anything domain related.

[archmoj]

Ok but for now let's just implement "remove past div" not anything domain related.

We already did implement 'remove past domain' functionality for inside tick labels and I am going to reuse that function for div.

[nicolaskruchten]

Can I see a demo of this remove past domain in action for inside tick labels?