A custom hover note should not disappear while the reader moves onto it. In a fictional desktop glossary, an information icon opens a note over the article paragraph. The reader needs to inspect the note and then uncover the paragraph without losing their place.
Follow the pointer through the example
Hypothetical example: the icon sits beside the term Room status. Hovering opens three lines of explanation. In version A, moving the pointer from the icon onto the explanation closes it immediately. The reader sees the first line but loses the remaining text when trying to reach it.
Version B keeps the note visible as the pointer enters it. The reader moves across the three lines and finishes the explanation. A two-second automatic timeout would interrupt this same sequence even if the pointer had never left the note. These are different closing behaviours, not different meanings of Room status.
Uncover the paragraph without relocating
In the fictional version B, pressing Escape dismisses the note while the pointer stays still. The underlying sentence becomes readable again. This is an example implementation, not a promise that every interface supports Escape.
A close button that requires moving the pointer away is not equivalent to that stationary dismissal. Record what actually happens: where the pointer was, which action dismissed the note, and whether keyboard focus moved. Do not call a note usable merely because some way to close it exists.
Keep the scope precise
W3C describes custom additional content as hoverable and persistent, with dismissal possible without moving hover or focus. Dismissal exceptions include input errors and non-obscuring content; browser-controlled, unmodified tooltips are exempt. The note may end when the trigger is removed, it is dismissed, or its information becomes invalid. See the W3C hover and focus explanation.
This comparison concerns a desktop pointer interaction and a made-up glossary. It neither invents mobile hover behaviour nor reports an audit of Jai Club Games.