New component: HoverCard

An example of a HoverCard.

https://user-images.githubusercontent.com/805073/114011235-eb7a3500-985c-11eb-9448-412b49479611.mov

This component would be primarily for sighted users. It should only be used on links with a href. It should only ever display content that is available on the href.

A rough feature-set for HoverCard:

• Popper positioning. I assume we can reuse our utility for this?
• Trigger delay (research whether to use same delay as tooltip. Potentially use the same code and link them globally? Gotta do some thinking there.)
• Support for Arrow or no Arrow.
• Close on ESC.
• Don’t trigger on focus.
• Try to avoid what twitter does where you can reopen the HoverCard if you hover its container before the close animation has completed?
• Should work well with Slot.

No focus trapping. No focus management at all.

[andy-hook]

I had a quick look at other uses of this pattern out in the wild

Dribbble

Github

Behance

Wikipedia

Interestingly, wikipedia positions content based on the entrance coord:

https://user-images.githubusercontent.com/11708259/114038329-afa19880-9879-11eb-81ac-594217ff610d.mov

My initial thought is that we don’t need this complexity and that a side prop (ala Tooltip) would suffice?

Visibility Delay

This is interesting because these cards might want to make lazy requests / async sides for content or assets, you could argue that you might want to change the visibility delay independently from the trigger for controlling perceived performance? perhaps that’s not this components responsibility?

Dynamic content size

Do we want to provide some type of internal mechanism (resize obs?) that will update the collision if the content size changes after first render? perhaps this isn’t necessary but I can imagine some scenarios where there is an async content update that screws with collision, or is popper smart enough to deal with this now?

The other points in the original outline look good to me. Having looked at common uses I think it’s safe to expect additional interactive elements within cards and to make sure our visibility logic is tactile and doesn’t interfere.

I guess if we wanted a distinction we would say that the presence of other interactive elements is what differentiates this implementation from a Tooltip? I (surprisingly) couldn’t find many good examples of it in other popular libraries, please point me at some if you have though!

[andy-hook]

Thanks for the feedback on this @benoitgrelard, I thought about it some more and I’m leaning into simpler the better. If a user wants a 0 delay on exit they can do this and everything does work predictably, as expected. We expose all the options needed to create working abstractions without exit delays e.g. offsets are fully customisable.

Happy to discuss if we think we need to account more for this, for now I’ve raised a PR here