@alexshoe this looks great! Really nice codepen, does a great job showing the feature and how to use it 🎉 But the pseudo-spikeline is a little off. There are actually two ways you might want this to behave, and both have some issues today.

(1) Follow the cursor even if there's a data point to hover on. That's mostly what happens in the codepen as written right now, except that when you DO get a data point, we stop emitting hover events until you get a different data point. This means that the pseudo-spikeline gets stuck at the first mouse position where plotlyjs picked a particular data point, until you get to a position where it picks a different data point. Seems to me when we have hover anywhere - and maybe also when we have spike lines snapping to the cursor? - this means we need to emit a hover event, and update the hoverdata so the click event will get the proper coordinates, on every mouse move even if the hovered data point exists and has not changed.

(2) Stick to the data point when you're hovered on one, or follow the cursor when not near a data point. For this flavor I think we have all the events we need, and if you make the pseudo-spikeline out of a shape, I think we have all the information we need in the event. But if you make the pseudo-spikeline out of a raw DOM element, d.event.offsetY isn't correct when you have a data point, you need the actual pixel position of the data point. Personally I could probably get this using things like fullLayout.yaxis.d2p and fullLayout.yaxis._offset but we probably don't want our users to have to use our internals like this; better would be to publish the mouse location of the actual hover point as part of the event data.

@alexcjohnson Thanks for the comment and for going in depth in those two use cases. Do you think we should enable both of these modes with another attribute or maybehoveranwhere allows you to pick a mode where data points are non-sticky?

For point two, by "mouse location of the actual hover point", do you mean the pixel position of the mouse or the data point that we are close to? I think if we published the latter, we would be able to easily modify my CodePen such that the spikeline follows the cursor when not near a data point, then snaps to the exact position of the nearest data point, when close enough.

For point 1, there's a function in hover.js called hoverChanged. When the mouse moves but the closest data point hasn't changed, hoverChanged returns false and hover event emission is skipped. So we can just set it to NOT skip emission if hoveranywhere is true.

Curious to know what you think

Do you think we should enable both of these modes with another attribute or maybehoveranwhere allows you to pick a mode where data points are non-sticky?

I don't see that we need any new attributes here, just more events and more data in the existing events.

For point two, by "mouse location of the actual hover point", do you mean the pixel position of the mouse or the data point that we are close to? I think if we published the latter, we would be able to easily modify my CodePen such that the spikeline follows the cursor when not near a data point, then snaps to the exact position of the nearest data point, when close enough.

Yes, the latter. Specifically I guess the position where we would draw the spikeline, which can be different from the position of the data point or the position of the hover box in certain cases, like grouped bars where the data point and hover box are drawn to the bar, wherever it's aligned, while the spikeline is drawn to the data value.

For point 1, there's a function in hover.js called hoverChanged. When the mouse moves but the closest data point hasn't changed, hoverChanged returns false and hover event emission is skipped. So we can just set it to NOT skip emission if hoveranywhere is true.

That seems likely to give the behavior we want!

@alexcjohnson thanks for the clarification. I've made both changes so that:

1. Hover events ALWAYS fire if hoveranywhere is on, even if near a data point
2. Expose x- and. y-pixel values data points

I updated this codepen to reflect these changes too. You'll notice the spikeline now follows the cursor at all times, regardless of proximity to data points. There is also a new hover label that does snap to nearby datapoints, and shares the same color as the trace it references.

Excellent, thanks @alexshoe! The updated code and the new behavior in the codepen both look good to me now.

@camdecoster and @emilykl, whenever you get a free moment, would you mind taking a look at this PR? Thank you so much!

@alexcjohnson It occurs to me that perhaps these properties (hoveranywhere and clickanywhere) should be part of config rather than layout -- do you have thoughts on which location is more appropriate?

@alexshoe Can you document somewhere what xPixel and yPixel mean? I assume they're the pixel position of the hover/click, but relative to what? The upper left corner of the plot div?

@alexcjohnson It occurs to me that perhaps these properties (hoveranywhere and clickanywhere) should be part of config rather than layout -- do you have thoughts on which location is more appropriate?

Oh that's a good point - the original concept of config vs layout is anything that's not portable, ie it depends on the context in which you're displaying the plot, belongs in config. And these clearly aren't portable, because they depend on event handlers being attached to the plot. I'm not sure if this distinction is meaningful or intuitive to users (or as important as it what many years ago when we created it and Chart Studio, with its sharing and separate view, edit, and embed views, was the main consumer of these plots), and we've broken that convention with good reason when the context-dependent attribute is scoped to a particular component like one shape, subplot, or trace - certainly don't want to implement a parallel object structure just for config!

All that to say I don't feel strongly about it, but if you think these would be easier to find in config I can get on board.

@alexshoe I've finished my first pass review! All looks good, left some fairly minor comments.

Ideally this feature should add (almost) zero additional overhead when hoveranywhere and clickanywhere are false. Do you know whether that's the case? I'd have to do another pass through to confirm but maybe you've thought about this already.

@alexcjohnson It occurs to me that perhaps these properties (hoveranywhere and clickanywhere) should be part of config rather than layout -- do you have thoughts on which location is more appropriate?

Oh that's a good point - the original concept of config vs layout is anything that's not portable, ie it depends on the context in which you're displaying the plot, belongs in config. And these clearly aren't portable, because they depend on event handlers being attached to the plot. I'm not sure if this distinction is meaningful or intuitive to users (or as important as it what many years ago when we created it and Chart Studio, with its sharing and separate view, edit, and embed views, was the main consumer of these plots), and we've broken that convention with good reason when the context-dependent attribute is scoped to a particular component like one shape, subplot, or trace - certainly don't want to implement a parallel object structure just for config!

All that to say I don't feel strongly about it, but if you think these would be easier to find in config I can get on board.

@alexcjohnson Just closing the loop on this — I took a look at the options currently available in config vs. layout and basically I agree with what you've said here: perhaps in some abstract sense it might make more sense to put these options in config, but lately it seems we have been putting everything in layout so I don't see a reason to change that precedent for these options in particular. layout also has the option of being more discoverable via this figure reference page here and as far as I can tell we don't have an equivalent comprehensive docs page for config.