Implement per-subplot hovermode

[paulsputer]

It appears that when the cartesian axes are flipped (i.e change x to y, and y to x) in both layout and data the resulting chart whilst looking correct has a different UX, namely the hoverinfo.

{yaxis.type:'category'}
{xaxis.type:'linear'}
As expected moving the mouse from left to right displays the label cursors and values.

(unfortunatley the screen capture doesn't capture the cursor, but it is moving)

{yaxis.type:'linear'}
{xaxis.type:'category'}
Moving the mouse from bottom to top does not change the the hoverinfo. Only the hoverinfo for the last element in the data array is displayed. In addition the black cursor for hoverinfo would display the y axis and the blue cursor for hoverinfo would display the x axis.

Perhaps hoverinfo flaglist should interpret order of occurrence to determine which to move, or is there a more appropriate place to handle this?

[alexcjohnson]

Is this using the default hovermode='x' ("Compare data on hover" in the modebar)? You may have better luck with hovermode='closest' ("Show closest data on hover"), which I'm starting to think should be often or always the default...

When you use horizontal bar traces, we turn compare into hovermode='y', ie compare values with the same y value across multiple traces - which behaves as you seem to have in mind. We don't do that for scatter traces - I'm not sure we could find a robust condition indicating that we should make this switch. You can enable it explicitly with Plotly.relayout(gd,{hovermode: 'y'}), though if the user changes hovermode from the modebar it would revert.

[paulsputer]

Perfect, thank you, yes hovermode=closest works well. On first glance it looked as though we could do with hovermode being settable on a per trace basis just as hoverinfo is. Looking closer at the code in hover.js that might not be as easy it sounds when there are multiple traces, unless it defaulted to the layout.hovermode.

Would that be a useful feature here or is it perhaps too much of an edge case?

[alexcjohnson]

I guess hovermode actually controls two pieces of behavior:

• Can you get multiple labels, or at most only one? (x/y: multiple, closest: one)
• Which coordinates are used to determine distance to data points? (x: x, y: y, closest: both)

If we wanted this to be a per-trace attribute, we'd have to split those two apart, as the former isn't about the behavior of a single trace at all. But it strikes me as potentially confusing to have each trace behave differently in this regard.

We have discussed possible per-subplot control over hovermode, though we have no concrete plans to implement it. For example this plot might want closest in the main subplot, x on top, and y on the right:

[paulsputer]

Yea there looked to be a fair bit of logic in there, that makes sense. Certainly per-subplot is the way forward.

In my offline fork I've added such functionality though it's a bit hacky as I've added a _subplotoptions to the newFullLayout, perhaps the more elegant way would be using the existing _subplot but that looks like it contains generated string ID arrays for each subplot in each coordinate space. Turning them into fully fledged objects holding options looked like it would involve a lot of changes...

If you're happy with the addition of a _subplotoptions solution I can push a PR for review when I get a moment.

[alexcjohnson]

The _ attributes are derived items for internal use, not to be used as part of the API, so we wouldn't directly extend any of those.

There's nothing ordered about the subplots so we could make a data structure like:

subplots: {
    xy: {bgcolor: 'red', hovermode: 'closest'},
    xy2: {bgcolor: 'green', hovermode: 'x'},
    x2y: {bgcolor: 'blue', hovermode: 'y'}
}

Alternatively we could make it an array, which would be a little easier to square with our validation system:

subplots: [
    {id:'xy', bgcolor: 'red', hovermode: 'closest'},
    {id: 'xy2', bgcolor: 'green', hovermode: 'x'},
    {id: 'x2y', bgcolor: 'blue', hovermode: 'y'}
]

That said, we do have variable-name attribute containers (xaxis2, scene4) so we should be able to make the first one work, and I like the simplicity and inherent freedom from duplication. For example, to change the background color of xy2 you would just do:
Plotly.relayout(gd, {'subplots.xy2.bgcolor': 'red'})
rather than having to know which entry is xy2 and do
Plotly.relayout(gd, {'subplots[1]bgcolor': 'red'})

Before you do much work on this though, I'd like to get @etpinard 's opinion on the API, and he's out for the next week.

[paulsputer]

Ah yes, first way is how I have it currently implemented from the API perspective and then it copies over to the _ attribute internally. Anyway yes sure look forward to picking this back up when @etpinard returns.

[etpinard]

Ok if I change the issue title to Implement per-subplot hovermode ?

Referencing other per-subplot feature requests #977 and #233

[paulsputer]

Sure @etpinard that sounds more appropriate with the discussion focusing on subplots.

[gvwilson]

Hi - this issue has been sitting for a while, so as part of our effort to tidy up our public repositories I'm going to close it. If it's still a concern, we'd be grateful if you could open a new issue (with a short reproducible example if appropriate) so that we can add it to our stack. Cheers - @gvwilson