Proposal: New Tooltip API

[briangregoryholmes]

The purpose of this WIP PR is to propose a new Tooltip API to be used across the app.

Why?

• Remove dozens (and sometimes hundreds!) of DOM elements and listeners
• Components that use tooltips are made more complex by extraneous slots and wrapping elements
• Tooltips should not be thought of as an inherent part of a component, but rather as a layer/system that exists on top of the application as a whole
• Tooltips, which are primarily about accessibility/clarity, should not take precedence over accessible labels

How?

• Create a global "tooltip renderer" that has a single debounced mouse move listener
• If the cursor stays on an element for a certain timeout period, check if it has an aria-label and other custom data properties
• If it does, render a tooltip in the portal
• Enable reactive tooltip suppression (like when scrolling in the table) via MutationObserver

Additional Benefits:

• A new modifiedClick action that solves issues with the existing approach (multiple handlers can be called) and automatically adds a data-action property that the tooltip renderer can parse to display modified click descriptions

This PR illustrates this new approach in the SurfaceControlButton, NavigationEntry and Cell components. Currently, the implementation requires that the data-tooltip property be set so that it does not interfere with the existing system.

[djbarnwal]

This sounds great. Thanks for taking the initiative. Overall I think this is a good direction and would be great if we can do this incrementally.

Also, can we render complex HTMLs from aria-label? We have different tooltips, some showing shortcuts, titles, description etc. We might have a sparkline in the tooltip at some point. In some cases tooltips are linked for example in Big number with time comparison if you hover over different numbers, you'll see a different values in the tooltip but rest of the information is same and the position of the tooltip is preserved.