Tooltip position is centred on screen when target element spans across multiple lines.

[andyroberts]

If the element that triggers a tooltip spans across two or mores lines the tooltip appears centred on within the viewport rather than positioned close to the appropriate target element.

So you may have a paragraph containing "Some Link" which triggers a tooltip and the browser is at a particular width that causes the link to be split over two lines, i.e., "Some" at the end of line 1 and "Link" at the beginning of line 2. That's when the issue occurs.

I couldn't see anything in the docs that mentioned this as a known limitation.

[stevenbenner]

Now that is a conundrum. I never really thought of that use case.

What's happening is that since the text is wrapping, the browser sees it as essentially a big block. The left offset in the viewport isn't where the first letter of the string starts, but the furthest left position of the element, which makes sense when you think about it.

It is conceivably possible to handle this, but it could be complicated and potentially quite messy. I would have to determine if the target element is a text element, grab the getClientRects() for the text element to determine coordinates of the start and end of the string, then figure out how to place it based on the requested placement and the position.

I'll dig into this and see if it's reasonable, but I don't want to add a lot more code to support this use case so it may not happen. I'll update this issue when I know more or have an answer for you.

[stevenbenner]

It is unlikely that a fix will ever be implemented for this. The plugin would need to detect that an inline element has been wrapped in such a way that its box-center does not contain any content from the element, then somehow figure out the bounding box for each chunk of the split element, then determine which chunk wins the tooltip.

Unfortunately I don't think that is possible with the APIs available in the DOM.

Closing issue.