Tooltip, how to make it not "interactive"
Just speaking in terms of Tippyjs's way to make tooltips interactive or not interactive: https://atomiks.github.io/tippyjs/v6/all-props/#interactive
When interactive, if I hover on the tooltip trigger OR tooltip content, it stays open. (current Kobalte behavior) When not interactive, if I hover on the tooltip content, it closes. Only the trigger makes it stay open.
Is there a way to make it "not interactive" with the current Kobalte Tooltip primitive?
Keep in mind that this would be outside the scope of the tooltip pattern suggested by WAI-ARIA:
https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/
Tippy is not a library that was focused on following these guidelines, so the end goals would be different.
I would probably suggest using popover/hovercard to achieve this though, as they do not have to follow a pattern and can therefor be more expressive/flexible in how they behave. In any of these cases, you should be able to achieve this by controlling tooltip/popover state and wiring the onPointerEnter and onPointerLeave events for the trigger
A suggestion might be to implement the trigger with custom onPointerEvent enter and onPointerEvent exit events which utilize the exposed use____Context function which provides methods for opening and closing the popovers. Whenever you wish to use your own 'non interactive tooltip' hovercard/popover, then you would use your implementation of the trigger.
Just my thoughts though
Thanks for sharing your thoughts, no worries, yeah I think that makes sense. Think we can close this as out of scope.
Don't think it's out of scope as a feature request for a pattern, perhaps just not linked to the tooltip primitive (or at least I would suggest avoiding using the tooltip primitive for this; or consider whether this behaviour is desired). I would think this is more appropriate for the HoverCard to support and would also suggest using the suggested method above to achieve your outcome in the interim.
Would be a good place to provide some simple prop support. Judging from the source code comments, this is also the most likely api to change.