ticklabelindex property does not work for dticks spanning multiple periods #7423
Description
Problem description:
The current implementation of the ticklabelindex property does not work for dticks that span multiple periods when no minor ticks are present.
Please consider the following example (https://codepen.io/stephprobst/pen/MYYMjmr):
Due to setting '"ticklabelindex": -1', the label to the left of the major tick gets drawn (2023 / 2025) instead of the label to right of the major tick (2024 / 2026).
This is correct and works as it should. Now let's consider another example, where the minor ticks are not shown (https://codepen.io/stephprobst/pen/RNNzROd):
Even though '"ticklabelindex": -1' is set as before, the label to the right of the major tick (2024 / 2026) gets now drawn. This causes some issues for us, as we cannot rely on the ticklabelindex to always work as expected.
There is yet another scenario, where '"ticklabelindex": -1' does not work exactly as expected. Please consider this third codepen (https://codepen.io/stephprobst/pen/LEEKRBK):
In this example, instead of minor ticks we use "ticklabelstep": 2 for a similar layout. I would now have expected the '"ticklabelindex": -1' property to have the same effect as before with the minor ticks: Drawing the label to the left of the major tick (2023 / 2025). But this is not the case.
Why this is relevant:
The behaviour as described above prevents us from creating the following automation:
- Makes sure the last visible tick is a major tick
- Makes sure the label for the last data point is drawn
For both scenarios we set the tick0 property, but depending on the presence of minor ticks or the distance between the ticks the label behaves differently with `"ticklabelindex": -1' in place (which is our default).
Expected behavior:
The "ticklabelindex": -1 property should behave consistent across all the use cases listed above. In all examples, the labels 2023 and 2025 should be shown.
Activity
my-tien commentedon May 26, 2025
It's not straightforward how this issue should be solved. Currently,
ticklabelindexdetermines which minor tick's label should be shown. So when no minor ticks exist (or when theirticklenis 0), the property has no effect.The expected behavior here is that
"ticklabelindex": -1always draws the label to the left of the major tick. Some alternative solutions for this would be"ticklabelindex": -1a special case in which extra logic is implemented to draw the label left of the tick."ticklen": 0are still generated. Then one can maketicklabelindexwork with invisible minor ticks.Option 1. is not so nice because it adds a special case. And the
indexpart of the name doesn't make a lot of sense for that special case.Option 2. requires a little bit of a hack on user side to achieve the desired behavior.
Option 3. seems to be what we want semantically, but might be a little bit confusing because the behavior of
ticklabelindexwould then depend on how this new property is set.@stephprobst @emilykl @gvwilson What do you think about this? Is there another option 4.?
gvwilson commentedon Jun 3, 2025
@emilykl @archmoj thoughts on the best way forward?
emilykl commentedon Jun 10, 2025
@stephprobst @my-tien I spent a few hours yesterday looking at this one. @archmoj @alexcjohnson please correct me if I'm making any false assumptions.
I think the behavior definition for
ticklabelindexis pretty clear, and we should stick to it: "Instead of drawing the major tick label, draw the label for the minor tick that is n positions away from the major tick."I think that the root issue in both of ths, if the minor ticks are not visible (either because
ax.minoris not defined, or because some other combination of values causes us to decide not to draw the minor ticks), we never even calculate the minor tick positions; therefore there are no values to choose from when trying to pick a value to use forticklabelindex.My thought:
If
ax.ticklabelindexis passed, regardless of whether any values are provided forax.minor, we should calculate positions for all minor ticks (using default values if necessary), and then use those values to select the correct minor tick label to display, according toax.ticklabelindex.I do also feel that setting
ticklabelindexwithout setting adtickfor the minor ticks is not a great idea, since AFAIK we don't guarantee any particular default spacing for minor ticks, so you don't necessarily know exactly what minor tick label you'll get. Nonetheless, there's no reason we can't support it, while still recommending thatminor.dtickbe defined for predictable behavior.my-tien commentedon Jun 11, 2025
Hi Emily,
that's an interesting idea. I just wonder if the feature isn't too weird in the sense that you probably never want to create a chart like this where the major tick interval is 3 years and minor ticks are invisible but have an interval of 1 year and
ticklabelindexis 1:This is strange because each label individually looks as if it labels the whole span between the two ticks while in reality it just denotes an invisible interval in between.
Yet another idea:
Introduce special keywords
leftandrightas values forticklabelindex.rightwould be identical toticklabelindex0 andleftwould just draw the label on the left of the major tick.stephprobst commentedon Sep 4, 2025
@emilykl , @gvwilson - Any progress on this issue? Anything else you'd need from our side to move this forward? I think the proposal by My-Tien to implement
leftandrightas special keywords seems good to me? This should be fully backwards compatible, as it only introduces new options and the implementation effort should also stay reasonable? Thanks!gvwilson commentedon Sep 9, 2025
hi @stephprobst - my apologies for the radio silence - Plotly Studio and Plotly Cloud are launching today, so all of our efforts have been focused on that.
stephprobst commentedon Sep 22, 2025
Hi @gvwilson, hi @emilykl, congratulations on the launch. We'll make sure to check out the new tools. And thanks for giving this issue priority.
my-tien commentedon Mar 23, 2026
Hi all, I am happy to pick up the issue. If there are no objections I'd go with the solution to add keywords
left,right(or some variety of that?).emilykl commentedon Mar 24, 2026
Hi @my-tien ! 🙂
I don't have any particular objection to adding keywords, but I don't think
leftandrightare the correct choice because they aren't appropriate for vertical axes. (Their behaviour would also need to be reversed in the case where the axis itself is reversed, although that's easier to deal with.)I still believe the cleanest solution is:
ticklabelindexis set, we should calculate what the minor ticks WOULD be, if they were shown. Thenticklabelindexrefers to those hypothetical ticks.I'm not sure how
leftandrightcan have any useful meaning without knowing the minor tick spacing.Let me know if I'm misunderstanding!
my-tien commentedon Mar 25, 2026
Hi Emily, the case with the vertical axes is very true! I think, the issue that I raised in this comment (i.e. that it would be possible to create misleading axis labels) can be delegated to the user's responsibility.
I will have a look into disabling the skipping of minor tick label calculation when they aren't visible, as you suggested.
emilykl commentedon Mar 25, 2026
@my-tien Ok! Let me know if you think that will work.
As I wrote above, I'm not opposed to adding keywords but I think the actual problem of calculating the minor tick locations will have to be solved regardless, and the keywords are optional.