Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always overlap modebar with hoverlabels #3471

Closed
Braintelligence opened this issue Jan 24, 2019 · 12 comments · Fixed by #3589
Closed

Always overlap modebar with hoverlabels #3471

Braintelligence opened this issue Jan 24, 2019 · 12 comments · Fixed by #3589
Assignees
Labels
bug something broken

Comments

@Braintelligence
Copy link

Hi there, it would be awesome if we could avoid this:
grafik
No matter if I put the modebar to orientation = v or h hoverlabels on the right side will land behind the modebar and thus be hard to read. Especially bad for narrow displays.

I tried to make the modebar only appear on hover as demonstrated in some issues/PRs but I couldn't find such an option.

Other than that I can't think of a situation where you'd not want hoverlabels to always overlap the modebar.

@etpinard
Copy link
Contributor

Thanks for the report!

What's the best solution here in your mind? Show the hover labels above the mode bar (but then the modebar wouldn't be accessible). Show the hover labels on the other side of the data points (on your graph, that's to the left)?

In the meantime, I suggest increasing the right margin layout.margin.r so that both the modebar and the hover labels fit on the right-hand side of your graph.

@alexcjohnson
Copy link
Collaborator

(but then the modebar wouldn't be accessible)

But that's only when the mouse is over the data anyway, right? Hover labels will disappear when you mouse off the plot and onto the modebar, won't they?

Seems like this may require a third top-level <svg> element just for hover labels... but I agree that putting them in front of everything else is the ideal behavior.

@etpinard
Copy link
Contributor

But that's only when the mouse is over the data anyway, right?

What happens if one hovers over a hover label that sits outside the subplot domain? I think the hover labels stays, but I'd have to check.

@alexcjohnson
Copy link
Collaborator

Pretty sure hover labels themselves don't interact with the mouse at all... hovering over the label, whether it's on or off the subplot, does nothing to keep it from disappearing if the mouse isn't in range of the associated data point/object.

@etpinard
Copy link
Contributor

There's this block:

hoverLayer.onmousemove = function(evt) {
evt.target = gd._fullLayout._lasthover;
Fx.hover(gd, evt, fullLayout._hoversubplot);
};

but yeah I'm not sure it actually does anything.

@alexcjohnson
Copy link
Collaborator

If anything that block is what ensures we pass the event on to the subplot rather than the hover label keeping it. But yeah, in principle if the hover labels are created correctly this shouldn't be necessary.

@Braintelligence
Copy link
Author

Thank you guys for your quick and considerable replies.

I'd prefer having an almighty everything-overlapping hoverlabel.

Adding left or right margins is a no-go because I need the full width that I can get for 360px wide displays. 😭

@etpinard etpinard added the bug something broken label Jan 24, 2019
@etpinard etpinard assigned etpinard and antoinerg and unassigned etpinard Jan 31, 2019
@antoinerg
Copy link
Contributor

antoinerg commented Jan 31, 2019

I'm not sure what's the best way to solve this. The modebar is a div so it's not going to respect the order of drawing of SVG. I could, however, add a CSS z-index to both the modebar div and the top layer SVG and make sure the latter is larger. Would that be satisfactory?

modebar has z-index: 1001 which is why it wouldn't respect order of drawing.

@etpinard
Copy link
Contributor

etpinard commented Feb 4, 2019

modebar has z-index: 1001 which is why it wouldn't respect order of drawing.

Hmm, right. This is annoying. Maybe we should start thinking seriously about moving the modebar buttons into

image

aka fullLayout._toppaper along side <g.hoverlayer> and draw them purely in SVG. This would allow us to 🔪 the numerous Lib.addRelatedStyleRule calls in modebar/modebar.js.

@antoinerg
Copy link
Contributor

@etpinard Another solution is to remove that z-index on the modebar container and to order it properly with the other DOM elements. To resolve the current issue, we could place a third SVG element containing the hoverlabels which would be drawn above modebar. If you are open to this idea, I could add it to PR #3500

@anders-kiaer
Copy link

A related Dash issue, if relevant here as well:
https://community.plot.ly/t/modebar-appears-on-top-of-dropdown-list/6398

To reproduce:

import dash
import dash_html_components as html
import dash_core_components as dcc

app = dash.Dash(__name__)
app.layout = html.Div([
    dcc.Dropdown(
        id='my-dropdown',
        options=[
            {'label': 'New York City', 'value': 'NYC'},
            {'label': 'Montreal', 'value': 'MTL'},
            {'label': 'San Francisco', 'value': 'SF'}
        ],
        value='NYC'
    ),
    dcc.Graph(
        id='example-graph',
        figure={
            'data': [
                {'x': [1, 2, 3], 'y': [4, 1, 2], 'type': 'bar', 'name': 'SF'},
                {'x': [1, 2, 3], 'y': [2, 4, 5], 'type': 'bar', 'name': u'Montréal'},
            ],
            'layout': {
                'title': 'Dash Data Visualization'
            }
        }
    )
])

if __name__ == '__main__':
    app.run_server(debug=True)

image

@antoinerg
Copy link
Contributor

Thank you @anders-kiaer for reporting this issue! I think your issue and the one originally described here are related. In your Dash app, the mode bar appears over the selection menu because its z-index is set to 1001. We shouldn't rely on this CSS style to make the mode bar appear above other elements but instead, we should draw it in the right order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants