Better support for multiline spans

[philippkuehn]

When using tippy on an element that is split between two lines, the default behavior is something like that:

There was already this issue with a suggestion to use followCursor.

So when using followCursor: 'initial' with placement: 'bottom' the placement is weird (target is hidden) sometimes:

So when using followCursor: 'horizontal' the offset is wrong:

Is there anything I missed to improve the position of the tooltip?

[atomiks]

https://atomiks.github.io/tippyjs/v6/all-props/#inlinepositioning?

[philippkuehn]

Yeah, now it’s… different 😅

[atomiks]

Yeah... I wanted to work on that for a while but for some reason it never worked fully reliably if the cursor entered the edges. If you can think of a solution please send a PR 😓

[atomiks]

For anyone interested in helping develop this feature, as I think it's pretty complex:

You need to be able to choose which rect to use based on two things:

1. Where the cursor entered from
2. The placement of the tippy

For example:

• The cursor entered from the bottom of the left part (the orange rect):
  — top placement: virtual rect is the green rect above it
  — bottom placement: virtual rect is the orange rect itself

• The cursor entered from the bottom of the very right part (the pink rect):
  — top placement: virtual rect is the blue one above it
  — bottom placement: virtual rect is the pink rect itself

• The cursor entered from the bottom of the purple rect to the right:
  — top placement: virtual rect is the green rect, but only if the cursor is to the left of the blue rect
  — bottom placement: virtual rect is the purple rect itself

[atomiks]

An alternative:

Detect if the two rects are "disjoined" and use a simpler version of the above, and if they're connected, use the current behavior? 🤔

[atomiks]

Install v6.2.1 and it should work well now

[philippkuehn]

Hey, great! It’s much better! However there is a bug when the cursor comes from the left side. But it’s not always. The first example works as expected. The second doesn’t. 👀

[atomiks]

Noo 😢 that's the issue I mentioned haha, but I didn't encounter it this time. I used 1px buffer too, do you have any ideas?

[atomiks]

I can't reproduce it myself for example, but I know I encountered this last year when trying to add the feature 👀 Maybe a 2px buffer 😅? Can you try editing node_modules/tippy.js/dist/tippy.esm.js with 2 instead of the 1 in the link above?

[philippkuehn]

Haha, yeah 2px works for me! 😅

[atomiks]

I also use 2px default for interactiveBorder, and haven't had any issues with that since 2017, so hopefully it's a "safe" value. I have no idea why .clientX/Y from the MouseEvent wouldn't be within the 1px-buffered bounds of .getClientRects() (accounting for rounding errors), but anyway...

[atomiks]

I published 6.2.2 @philippkuehn, let's hope 2 is enough or we might need a different solution D:

Also it falls back to the old inlinePositioning instead of the standard rect so it should be a little bit better in the worst case.