add style customization to hoverlabel

[Lexachoc]

Addresses some requests in #2342 without closing it.

This PR adds several new hoverlabel styling options based on the discussion in #2342.

New options:

• hoverlabel.borderwidth — sets the hover label border width
• hoverlabel.borderradius — sets the hover label border radius
• hoverlabel.borderpad — sets the padding between the text and the border
• hoverlabel.namecolor — sets the secondary hover label text color
• hoverlabel.bgnamecolor — sets the secondary hover label background color
• hoverlabel.shadow — sets a drop shadow on the hover label

Additional improvement

If hoverlabel.namecolor is not specified, the trace color is preserved when it has sufficient contrast against the secondary label background (WCAG 4.5:1). Otherwise, a contrasting text color is used automatically.

(Not sure whether this contrast improvement change belongs in this PR. Happy to move it out if preferred.)

Before/After

See the comparison in #2342 (comment).

[Lexachoc]

Suggested change

	- Add `hoverlabel.borderwidth`, `hoverlabel.borderradius`, `hoverlabel.borderpad`, `hoverlabel.namecolor`, `hoverlabel.bgnamecolor`, and `hoverlabel.shadow` styling options [[#8115](https://github.com/plotly/plotly.js/pull/8115)]
	- Add `hoverlabel.borderwidth`, `hoverlabel.borderradius`, `hoverlabel.borderpad`, `hoverlabel.namecolor`, `hoverlabel.bgnamecolor`, and `hoverlabel.shadow` styling options, and improve text contrast for secondary hover labels [[#8115](https://github.com/plotly/plotly.js/pull/8115)]

[camdecoster]

Thanks for the PR! Our team will review and follow up.

[Lexachoc]

BTW, I just realized that there are currently no controls for the width of either the main hover label or the secondary hover label, and there is also no automatic text wrapping.

This has actually been requested before:

Width / automatic wrapping

• Automatic hover text wrapping #1964 — automatic hover text wrapping / hover text width
• Fixed-width hover labels with hoverlabel.width #3800 — hoverlabel.width

#3800 was closed during the repository cleanup, but the requested hoverlabel.width feature was never implemented. In fact, it was previously suggested that adding hoverlabel.width with pixel values would be a reasonable addition.

I think it may make sense to add:

hoverlabel: {
    width: 200,
    maxwidth: 300
}

where width sets an explicit width, while maxwidth preserves the natural width up to the specified limit and automatically wraps text beyond it.
This should apply independently to both the main hover label and the secondary (<extra>) hover label.

Hover label positioning

While looking into this, I also noticed that the positioning problem I reported in #7330 is closely related to the much older issue #381:

• Hovertemplate will block the point due to the lack of top and bottom side #7330
• Display hover text on top instead of to the right #381

#381 has been open since 2016 and includes a proposal for: hoverlabel.position

with values such as:

 'auto', 
 'top left', 'top center', 'top right',
 'middle left', 'middle center', 'middle right',
 'bottom left', 'bottom center', 'bottom right',

ref: #381 (comment)

IMHO, I think options: "auto" | "top" | "right" | "bottom" | "left" would be enough for normal use cases.

---

Above may also be worth considering but in separate follow-ups.

[KoolADE85]

Hey @Lexachoc thanks for the submission here! I was about to review it, but noticed there are conflicts with a previous PR. I'll jump on this for a closer look after the conflicts are cleared up.

[Lexachoc]

Hey @Lexachoc thanks for the submission here! I was about to review it, but noticed there are conflicts with a previous PR. I'll jump on this for a closer look after the conflicts are cleared up.

Oops, no problem, I'll let you know once I've resolved the conflicts.

[Lexachoc]

@KoolADE85 I merged them.

You can play with it using the mock below:

{
  "data": [
    {
      "x": [1, 2, 3, 4],
      "y": [10, 15, 13, 17],
      "mode": "markers",
      "name": "$\\alpha_{1c} = 352 \\pm 11 \\text{ km s}^{-1}$",
      "type": "scatter",
      "marker": {
        "opacity": 0.5
      }
    },
    {
      "x": [2, 3, 4, 5],
      "y": [16, 5, 11, 9],
      "mode": "lines",
      "type": "scatter",
      "opacity": 0.5
    },
    {
      "x": [1, 2, 3, 4],
      "y": [12, 9, 15, 12],
      "mode": "lines+markers",
      "type": "scatter",
      "opacity": 0.707,
      "marker": {
        "opacity": 0.707
      }
    },
    {
      "x": [1, 2, 3],
      "y": [1, 2, 3],
      "opacity": 0.2,
      "line": { "width": 10, "color": "red" },
      "marker": { "size": 20, "color": "blue" }
    }
  ],
  "layout": {
    "title": {
      "text": "hovermode='closest'"
    },
    "hoverlabel": {
      "borderwidth": 5,
      "borderradius": 20,
      "namecolor": "red",
      "bgnamecolor": "yellow",
      "shadow": "0 10px 4px rgba(0, 0, 0, 0.2)",
      "borderpad": 15,
      "namelength": -1
    },
    "hovermode": "closest"
  }
}

However, I noticed two issues:

1. LaTeX positioning in hovermode: 'y':
   The rendered LaTeX expression is incorrectly positioned when using hovermode: 'y':

I reverted to the original hover.js from #8051 and reproduced the same issue:

---

2. LaTeX not rendered in unified hover modes (existing limitation):

LaTeX expressions are not rendered when using hovermode: 'x unified' or hovermode: 'y unified':

I also reproduced this behavior using the original hover.js from #8051.

Both are reproducible with #8051's original implementation, so they do not appear to be caused by this merge.