Hover rules for period-positioned traces

[nicolaskruchten]

These invariants should hold for period-positioned traces (the word "point" below should be taken to mean scatter marker or bar or whatever other kind of period-positioned mark we have) in both compare and unified hovermodes:

• a period-positioned point must not "win the hover" if the cursor is not within the period that the point represents (i.e. a scatter point with x='2010-02-15', xperiod='M1', xperiodalignment='start' must not win the hover even if the cursor is extremely close to it on the left side)
• a period-positioned point must be in the "hover set" (for compare or unified hover modes) if the point that wins the hover is within the period that the point represents (i.e. a scatter point with x='2010-02-15', xperiod='M1', xperiodalignment='start' must be in the hover set if the cursor is positioned at March 2 and the non-period-positioned point that won the hover is at Feb 28)

cc @alexcjohnson

See also #5292

[nicolaskruchten]

Open questions:

1. does the code already basically intend to do this?
2. do we need to find specific cases where these are not met?

[archmoj]

The behaviour using v2.0.0-rc.1 appears to be correct.
Here is a codepen.

[nicolaskruchten]

Funny observation regarding the codepen above: if I turn spikelines on, it's easy to get the spikelines on the bar but not the black axis-hoverlabel.

I think this exposes an additional implicit invariant: the "winning point" is the one that gets both the spikeline and the black axis-hoverlabel, right @alexcjohnson ?

[nicolaskruchten]

Also, I notice that the spikeline behaves differently in compare and unified modes: the spikeline in compare mode seems to want to stick to the bar, but in unified mode it has the behaviour I think I would expect.

I think that the relationship between unified hovermode and spikelines is that we coerce the spikedistance and/or spikesnapdistance when we set hovermode to unified. The spikeline behaviour in unified mode seems better to me, but maybe there is some additional context around spikeline/snapping behaviour that I don't know about.

[nicolaskruchten]

Re spikeline and winning point: there is the xaxis.spikesnap attribute which does not default to hovered data (although maybe it should, as part of 2.0?). I'll note that setting it to "hovered data" doesn't actually cause the winning point and spiked point to match :)

Also, in the codepen above, hovering on the left-most bar at exactly the center produces TWO orange hoverlabels in compare mode!

[nicolaskruchten]

Additionally: hovering over the exact center of the right-most bar causes the wrong point in the orange trace to be in the set! Oddly, this does not happen when I set the bar trace's xhoverformat="%m" (so we're doing string matching?)

[nicolaskruchten]

Let's ignore anything to do with spikelines in this issue and have that conversation in #5619