Describe in detail the issue you're having.
we use the default position on the tooltip component, which make the tooltip coming below the trigger element. problem comes when the trigger element is at the bottom of the screen and the tooltip will render partially outside of the edge.
body element. Is this a feature request (new component, new icon), a bug, or a general issue?
Bug
Is this issue related to a specific component?
Yes, tooltip
What did you expect to happen? What happened instead? What would you like to see changed?
I expect the tooltip is somehow smarter to calculate its available space and switch to display to the opposite side of the trigger element.
What browser are you working in?
IE 11 and above, Firefox, Chrome
What version of the Carbon Design System are you using?
"carbon-components": "^7.0.0"
"carbon-components-react": "^5.19.0",
What offering/product do you work on? Any pressing ship or release dates we should be aware of?
Information governance catalog/Unified governence
Sandbox: https://codesandbox.io/s/1znmwy5kx7
IBM github issue: https://github.ibm.com/InformationServer/igc-ui-react/issues/2220
can provide more information if the issue link above doesn't have enough
Hi @nelsonchen90 thank you for taking time to enter this issue! The recommended pattern for that scenario is being concious about where the trigger button is placed and setting the direction property accordingly. Hope it helps!
@asudoh Thanks for the promptly reply. the sanbox example just to to show the tooltip will go out of bound.
For our case, the position of the the trigger element is unknown until rendered. and even then, the trigger element will still be moving around with some scrolling. Basically I am trying to say that it's unknown at design time where the element is going to be.
Allow us to try your suggestion any way to see if we can get a compromise. In the meanwhile, if you don't mind, I'd like to keep this issue open
Hi, I tried the direction property,it doesnt work for dynamic placement.
It just give either top or bottom.
Is there any other to set the direction of tool-tip dynamically?
@srigoaki Thank you for trying to do additional report - For us to better understand what issue you hit, is it possible for you to create a reduced test case, e.g. based on this CodeSandbox template? Thanks!
Hi @asudoh ,Thanks for the reply.
I just kept some test code in sandbox,here is the link https://codesandbox.io/s/x2mjypo6pp.
On hovering only on the last tooltip,content is being cut off,so can i keep only the last tooltip direction to top or can i keep auto direction?
Sry,This is the link https://codesandbox.io/s/pwyxr8l9mq
Thanks @srigoaki for providing the example, looks that the tooltip is placed in very dense manner - I'd add more space around each one, and then setting the direction property as suggested in https://github.com/carbon-design-system/carbon-components-react/issues/763#issuecomment-377346463 for the very last one or two.
Thanks @asudoh , Will be waiting for that property.
@asudoh
Hi, I think @srigoaki 's sandbox should be this:
https://codesandbox.io/s/7oj4vqom31
We are generating those Tooltips DYNAMICALLY so we wouldn't know where it was placed or the content on the tooltip. In this example, If we say we only show the tooltip on top because the Element is at the end of the array, it won't suffice because there is scroll behavior and maybe the 20th one or 34th one is already on the bottom edge of the screen (depending on the clients size). and after scrolling up/down, the position of the element changed so we need the tooltip to be dynamic to decide its visible position...
I see - Thank you for articulating @nelsonchen90! Will take a note and see if a solution can be rattled off.
What should our actionable item be from this @asudoh?
Looking at the current <FloatingMenu>/<OverflowMenu>, I see a set of API (props) that @nelsonchen90/@srigoaki may want to try, which is, menuOffset/menuOffsetFlip. A function, taking the DOM node of floating menu body and the original direction as its arguments, can be used there which allows changing floating menu position depending on the condition e.g. what you described. If more info is needed to calculate the adjusted position, we can definitely add arguments there or consider exposing the whole position calculation code. Let us know if it works - Thanks!
I started the work on it and raise a PR for @asudoh to check
We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. Thanks for your contributions.
Hi there! :wave: If you're wondering why this issue was moved, we're currently updating our repo structure so that every package is found in the same project.
This should not have any impact for you, but we wanted to give you a heads up in case you were wondering what is going on. If you have any questions, feel free to reach out to us on Slack or contact us at: [email protected]. Thanks!
We've marked this issue as stale because there hasn't been any activity for a couple of weeks. If there's no further activity on this issue in the next three days then we'll close it. You can keep the conversation going with just a short comment. Thanks for your contributions.
As there's been no activity since this issue was marked as stale, we are auto-closing it.
Most helpful comment
@asudoh Thanks for the promptly reply. the sanbox example just to to show the tooltip will go out of bound.
For our case, the position of the the trigger element is unknown until rendered. and even then, the trigger element will still be moving around with some scrolling. Basically I am trying to say that it's unknown at design time where the element is going to be.
Allow us to try your suggestion any way to see if we can get a compromise. In the meanwhile, if you don't mind, I'd like to keep this issue open