Hovertemplate display of X value of points in hoverset that differ from that of the winning point

[nicolaskruchten]

Right now, in compare and unified hover modes, it's possible for points to be in the hover set and still have slightly different X values from that of the point that won the hover, and in this case we show the differing X value in parentheses in the hoverlabel.

We need to be able to show this value when hovertemplate is active as well, possibly via some new hovertemplate %{value} that is empty if the X value matches that of the winning point, and contains "(%{x})" otherwise.

This should honor the new (x|y)hoverformat attributes too.

[nicolaskruchten]

Let's call it (x|y)other for now.

[nicolaskruchten]

even when the X values match, if their xhoverformats do not, then xother should show the other value.

[archmoj]

It appears that there would be cases that the period positioned points are the only one presented in hover.
How about instead of (x|y)other we use (x|y)period and only target period positioned points?

[nicolaskruchten]

I believe there is some small tolerance even for non-period-positioned traces to contribute points to the hoverset in hovermode=x even when the x values don't exactly match, no?

[nicolaskruchten]

@archmoj it would be really great to get this one done this week if possible.

[archmoj]

@nicolaskruchten now using rc2 which implemented the winning point concept I made a simple codepen.
Looking at the current behaviour I think the users may by confused by the x, additions coming before y values added here:

plotly.js/src/components/fx/hover.js

Line 1286 in f83a962

else text = '(' + d.xLabel + ', ' + d.yLabel + ')';

Isn't that something we want to change in v2? e.g. can't we provide differing x inside parentheses after y or something?

[nicolaskruchten]

I'm not sure I understand what you're asking here... can you clarify please?

[archmoj]

I'm not sure I understand what you're asking here... can you clarify please?

Nevermind, actually it's not that line that adds differing positions :)

[archmoj]

OK. I commented the hovertemplate in above codepen.
In that case when hovering over scatter points while reading Y values the user will see the (x2, y2) value on the bar.
I think this confusing whereas the most important value in hover is Y not the x2 that came first.
So we should possibly change this behaviour in v2 to something like y2 (at x2).

On another note right now with hovertemplate one could easily format hover on bars.
If so wondering what the point for this new feature is?
Could you please provide a simple example of use?

[nicolaskruchten]

The use case is when you have, say, quarterly bars and monthly scatters AND you're using hovertemplate and unified hover. Right now when you hover on a scatter point, you don't get the indication about the X-coordinate of the bar. If you don't use hovertemplate you do, so we need to add this capability to hovertemplate.

I think that using (x, y) is quite conventional and I don't think we should change it in v2.

[nicolaskruchten]

Basically the use case is this: https://codepen.io/nicolaskruchten/pen/MWpEQqZ?editors=0010 ... on line 15 we want to be able to add %{xother} or something so that the Q1 will appear in the unified hoverlabel.