Repository navigation
Implement hovertemplate for all traces that support hover #3437
Description
Building on top of #3126, #3284, #3398 and #3436 hovertemplate is now supported for trace types: scatter, bar, pie, histogram, scattergl, sankey, scatterpolar, barpolar, scatterternary, scatterpolargl, choropleth, scattergeo and scattermapbox.
The "missing" trace types are:
-
contour,heatmap,histogram2d,histogram2dcontour -
boxandviolin(for points done in Hovertemplate for box/violin points #3685 | otherwise not implemented) - all the gl3d trace types:
scatter3d,surface,mesh3d,stremtubes,cone,isosurface -
scattercarpet -
ohlcandcandlestick -
splom -
parcats pointcloud,heatmapglandcontourgl(are we deprecating those trace types in v2?)
cc @nicolaskruchten
Activity
[-]Implement `hovertemplate` for all trace that support hover[/-][+]Implement `hovertemplate` for all traces that support hover[/+]nicolaskruchten commentedon Jan 14, 2019
Yup! I would say that scatter3d is the most important remaining one, followed by parcats and splom, then contour/heatmap/surface then the the histogram2d ones
mpf82 commentedon Jan 16, 2019
Personally, I would find it helpful and intuitive if for
boxthehovertemplatewould be applied to single points only, not affecting the other hover texts (such as median, min, lower fence, ...).There could be a separate property to handle these.
etpinard commentedon Jan 24, 2019
Cool, we'll try to fit these in
v1.45.0. Thanks for the info!nicolaskruchten commentedon Feb 9, 2019
If I can revise my original priority list, I might put @mpf82's suggestion above
parcats... It's pretty useful to be able to mouse over an outlier to know which one it is!etpinard commentedon Feb 10, 2019
Hmm. We haven't figured out the api for that one yet. See #3126 (comment)
We can't just make
hovertemplatejust work on box points, because at some point we'll want to implement hovertemplates on all box hover labels.nicolaskruchten commentedon Feb 10, 2019
I actually would find this to be most natural, and then we'd add
boxhovertemplateor similar for the non-single-point ones.etpinard commentedon Feb 10, 2019
I really dislike three-word attribute names, but I guess that would be one way to solve the problem.
In a similar way, we'll need to declare multiple
*hovertemplateattributes forparcats: one when hovering over links, and one when hovering over nodes.Sankey does a good job at this: it declares two
hovetemplateattributes: one inlink.hovertemplateand one innode.hovertemplate. Unfortunately, forparcatsandbox/violinwe don't have "nice" attribute containers like these to work with.Hmm well, I guess for
parcatswe could use thelinecontainer and then maybe coerce ahovertemplateinside eachdimensionsitem? Or maybe have the roothovertemplateapply to all the dimensions/nodes and be ignored when hovering on links?etpinard commentedon Feb 15, 2019
After #3530, only
box,violin,ohlc,candlestickand the old gl2d traces will be missinghovertemplatesupport.etpinard commentedon Mar 26, 2019
hovertemplate support for
boxandviolinpoints is implemented in #3685jackparmer commentedon Sep 10, 2020
This issue has been tagged with
NEEDS SPON$ORA community PR for this feature would certainly be welcome, but our experience is deeper features like this are difficult to complete without the Plotly maintainers leading the effort.
Sponsorship range: $5k-$10k
What Sponsorship includes:
Please include the link to this issue when contacting us to discuss.
gvwilson commentedon Jun 11, 2024
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
emilykl commentedon Nov 12, 2025
Reopening because still relevant