GeezerVison

I notice that this contrast fix will alter existing graphs when their trace colours do not meet the contrast standard.
For that reason, I would prefer to pull that change out of this PR and into its own issue where we can discuss some approaches. For those users who are happy with the way their graphs look, I'm cautious to casually change the colour-coding behaviour.

Sure. I've opened #8149 for discussion. I'll remove the automatic contrast logic and test after addressing the other review comments.

In the "unified" hover modes, the positioning of the hover labels do not account for border padding. As a result, the popup will appear in an unexpected location.

Example with exaggerated padding (notice where the cursor is!):

I think the unit tests could check for position here too, to catch any regressions.

Also on this topic: rounded corners are quite pixelated in this mode! This seems to be because the box is drawn with shape-rendering: crispEdges. I think we should use geometricPrecision or auto instead.

This doesn't take into account the border width, so it's possible for a thick border to clip some of the label text:

Annotations include the border in their size: borderfull = borderwidth + borderpad (draw.js#L218).

This would be a good candidate for a unit test as well!

The name box doesn't include the border or the radius which makes it look misshapen.

Without a stroke, the outline makes the name box appear to be a different size than the main box.
Example: (hoverlabel: { borderwidth: 8, borderradius: 20, bgnamecolor: 'black' })

With borderradius, it gets a bit trickier. There is no border rounding where the main box joins with the name box. These corners are square and, when there isn't any bgnamecolor, it looks like the rounding only applied to half of the label

Example: hoverlabel: { borderwidth: 4, borderradius: 12, borderpad: 12 }

These options are supported on every trace with hoverlabel but not in sankey. Can we also support sankey? #7451 had the same discussion for showarrow.

Other attributes support arrayOk for per-point array values, but these ones are excluded. Is that intentional? What do you think about supporting arrays here?

The rounded paths add three helpers (roundedRectPath, roundedSideArrowPath and roundedTopBottomArrowPath). The places that use these functions still keep the original hand-written paths using an if/else to decide which one to use.

Could we reduce duplication by creating a single helper that generically rounds the corners of a list of points?

Example fn signature:

function roundedPolygonPath(
  points: {x: number, y: number}[],
  radius?: number | number[] = 0,
  scaleX?: number = 1,
  scaleY?: number = 1
): string;

An array radius would be per vertex so the arrow corners can stay sharp.
A radius of 0 would be "square" (effectively a no-op for this fn).

The new tests only set the new hover options for the whole chart (layout.hoverlabel). Could we add a test that sets one on a single trace and checks it overrides the chart-wide value?