Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tooltips on SVG elements always appear at the top-left. #46

Open
cueedee opened this issue Jun 7, 2023 · 2 comments
Open

Tooltips on SVG elements always appear at the top-left. #46

cueedee opened this issue Jun 7, 2023 · 2 comments
Assignees

Comments

@cueedee
Copy link

cueedee commented Jun 7, 2023

We wanted to set a tooltip on an SVG element (<g> in this case). For reasons I do not claim to understand, jQuery's .outerwidth() and .outerheight() methods applied to such elements just claim that their dimensions are 0, but the result definitely is tooltips having their arrows always positioned at the top-left of that element.

Researching this a bit more turned up the suggestion to use the browser native method el.getBoundingClientRect() instead - here, here and here - for which a quick debug session revealed it to return all the positions and dimensions you could ever hope to need, all combined in one neat little package.

So the question bears asking if a desire to include support for SVG's would warrant incorporating the use of getBoundingClientRect, either in favor of-, or in addition to the myriad of currently employed jQuery utilities.

@stefangabos stefangabos self-assigned this Jun 8, 2023
@stefangabos
Copy link
Owner

sounds like a good idea. but there's more than just the <g> for a SVG. does it work when the tooltip is set on the <svg> tag? but i suppose you need it set on various parts of the SVG...
i'll look into it

@cueedee
Copy link
Author

cueedee commented Jun 9, 2023

jQuery's .offset(), outerWidth() and .outerHeight() do report the expected values when applied to an <svg>.

Interestingly, they also appear to handle the SVG <image> element correctly; so using that to embed the <g> contents as a separate <svg> could serve as a workaround I suppose. Not pretty, but it would work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants