-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
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
Allow tooltips to function on disabled elements #11601
Comments
@goyney The warning is here to highlight the problem so it doesn't stay silent. People might never realize that the tooltip is broken otherwise.
This expected behavior would require to automatically add an extra DOM node.
It's more than a workaround, it's a tradeoff we have taken that I believe is the best answer to all the constraints. Not implementing your expected behavior was a reasoned call. We have thought about it in the past. Right now, the tooltip is transparent from a DOM point of view. Automatically adding an extra DOM node can potentially break the layout and looks magically from a user point of view. I think that we should be explicit about this behavior, hence the warning.
At least we warn about it. I couldn't benchmark an alternative that handle the problem:
Regarding improving the anwser to the problem, I can think of two alternatives:
|
Bootstrap is documenting the workaround: https://getbootstrap.com/docs/4.1/components/popovers/#disabled-elements. |
@oliviertassinari Just want to chime in here and say I was bitten by this. Also, if this is intentional, I was looking for docs on MUI related to disabled controls and couldn't find anything. I would prefer a flag on the tooltip to support disabled elements as suggested above (I would have seen the flag in the API docs) but at the very least the API docs or demo docs for Tooltip should mention this caveat as it was non-intuitive and I found it via this issue. |
@kamranayub Let's document it 👍 |
If I can figure out how to contribute to the docs I can spend some time
tomorrow.
…On Mon, Jul 23, 2018, 13:48 Olivier Tassinari ***@***.***> wrote:
@kamranayub <https://github.com/kamranayub> Let's document it 👍
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11601 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAiaayqtG3zvBAEnlzYeO94FvF6l4okEks5uJhp1gaJpZM4UPIKT>
.
|
Dang super smooth docs experience, kudos. 👍 |
The current behavior means that tooltips either break button group rendering or don't work with disabled buttons in button groups. Edit: an additional annoyance is that the warning can't be suppressed. |
+1 to slikts, this is quite a nuisance |
Currently, when a tooltip is attached to an element which is in a disabled state, warnings are outputted in the console and the tooltip fails to operate. This is extremely annoying.
This bug is in reference to: #8416
Expected Behavior
When a tooltip is assigned to a disabled item, the tooltip works like normal. No console warnings or errors are produced.
Current Behavior
When a tooltip is assigned to a disabled item, it produces annoying console spam. Additionally, the tooltip does not display.
To work around this currently, every element that may become disabled is being wrapped in an empty
<span>
. This is less that optimal as it clutters the DOM with elements that are completely unneeded.Steps to Reproduce (for bugs)
https://codesandbox.io/s/rjjn7lx4rq
Context
Tooltips provide context. When a button is disabled, I need to convey to my user why that button is disabled. I currently cannot use tooltips to do this because of this limitation.
Additionally, I have a case where I have a toolbar of icons (20+) that, when content is loading, these buttons are in a disabled state. Once the content loads, the buttons enabled. In this case, the console is spammed with 20+ warnings, making it extremely hard sift through console messages when developing.
Your Environment
The text was updated successfully, but these errors were encountered: