You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Tooltip changes the width of children components #932
This is caused by the tooltip style and i'm sure is wanted.
Not always you set a div with size as the father of the tooltip, so when this is not present if it hasn't a w-fit, it's going to take up the entire page and cause issues. A solution would be to override the theme or add a className with w-full to override the w-fit.
Sorry, but I don't understand this behaviour as something wanted.
If you ask me what would I expect and desire from a Tooltip is that this component not affecting at all the screen and component design (as if it was not present).
Is there not a technical way to avoid the problem you mention without changing the children styles?
In my case, following your comment, I am going to use theme={{target: ""}}by the moment.
Thank you!
I agree with you that this is not the behavior I would expect. I'm sure there is a reason we have w-fit as the default here for tooltip.target, but I don't know why. It would be helpful if you could try removing w-fit from the theme on a fork and see if it breaks any of our examples on the Tooltip docs unexpectedly. If not, then I can't really see a reason to not just remove the default w-fit from the default theme.
Just tested in tailwind playground. I don't know if it's caused by tailwind or it's default html behavior, but the default behavior of a div is w-fit. So i'm pretty sure that just removing that won't change a thing.
@victorfunes@tulup-conner
Removing the w-fit breaks everything. It might work in some cases, but not in all of them, so I'm sure that removing it will surely break some site using the default settings.
Thanks. I'll convert this into a discussion for the future, then. This is probably a quirk with Floating UI, which we might be able to fix by moving w-fit further down the tree.
Activity
DavideFrancescon commentedon Aug 25, 2023
This is caused by the tooltip style and i'm sure is wanted.
Not always you set a div with size as the father of the tooltip, so when this is not present if it hasn't a w-fit, it's going to take up the entire page and cause issues. A solution would be to override the theme or add a className with w-full to override the w-fit.
victorfunes commentedon Aug 25, 2023
Sorry, but I don't understand this behaviour as something wanted.
If you ask me what would I expect and desire from a Tooltip is that this component not affecting at all the screen and component design (as if it was not present).
Is there not a technical way to avoid the problem you mention without changing the children styles?
In my case, following your comment, I am going to use
theme={{target: ""}}by the moment.Thank you!
tulup-conner commentedon Aug 25, 2023
I agree with you that this is not the behavior I would expect. I'm sure there is a reason we have
w-fitas the default here fortooltip.target, but I don't know why. It would be helpful if you could try removingw-fitfrom the theme on a fork and see if it breaks any of our examples on the Tooltip docs unexpectedly. If not, then I can't really see a reason to not just remove the defaultw-fitfrom the default theme.DavideFrancescon commentedon Aug 25, 2023
Just tested in tailwind playground. I don't know if it's caused by tailwind or it's default html behavior, but the default behavior of a div is
w-fit. So i'm pretty sure that just removing that won't change a thing.victorfunes commentedon Aug 25, 2023
Just if it could be useful for you: I changed in my application theme and everything that was broken after using Tooltips is working now.
DavideFrancescon commentedon Aug 25, 2023
I guess i'll have to test everything then. I'll do it tomorrow and update you all on the results.
DavideFrancescon commentedon Aug 26, 2023
victorfunes commentedon Aug 26, 2023
Thank you for your quick action and answer @DavideFrancescon
tulup-conner commentedon Aug 28, 2023
Thanks. I'll convert this into a discussion for the future, then. This is probably a quirk with Floating UI, which we might be able to fix by moving
w-fitfurther down the tree.