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

☂ Tooltip: open issues to resolve in converged approach #15102

Closed
dzearing opened this issue Sep 17, 2020 · 5 comments
Closed

☂ Tooltip: open issues to resolve in converged approach #15102

dzearing opened this issue Sep 17, 2020 · 5 comments
Assignees
Labels
Component: Tooltip Resolution: Soft Close Soft closing inactive issues over a certain period Type: Epic

Comments

@dzearing
Copy link
Member

dzearing commented Sep 17, 2020

Problems

The v7 Tooltip today is cumbersome to use. Some of the main painpoints:

  1. It wraps the content in a DIV, creating issues with CSS styling that very likely assume a different DOM shape.
  2. The DIV is inline, meaning that measuring the dimensions wraps around textual content rather than block content:

Expected:

image

Resulted:

image

The documented examples say the way to work around this is "use our styling api to set the container to inline-block." The right fix is to not use a wrapper element at all.

  1. The API surface is complex and things need to be scrubbed and reviewed:
  1. Hosting tooltips within tooltips does not do the right thing (dismisses everything.)
  2. When a tooltip is shown and you tab to another item which has a tooltip, the tooltip fades out/in, rather than just moving over (we should be more intentional about motion here.)
  3. The tooltip is hard to see from other content. Would be nice to be inverted.
  4. There is no central way to dismiss tooltips. There should be a way to raise an event, or call some universally accessible api to dismiss or possibly disable tooltips on the page. (E.g. a TooltipManager component?)

Proposals / Ideas

  1. Rename it to Tooltip. Let's not have a messy "host" suffix.
  2. No wrapper divs.
  3. Simplify API surface. (Needs some research and review.)
  4. Some imperative way to dismiss all tooltips. Tooltip.dismissAll() static could be nice.

Key issue capturing some ideas from awhile back

Active issues the need investigation

Understood issues that need fixing

Other related issues

@dzearing dzearing changed the title Tooltip: refactor Tooltip: open issues to resolve in converged approach Sep 17, 2020
@JustSlone JustSlone changed the title Tooltip: open issues to resolve in converged approach ☂ Tooltip: open issues to resolve in converged approach Sep 21, 2020
@smhigley
Copy link
Contributor

smhigley commented Oct 2, 2020

Re: tooltips dismissing with the ctrl key -- this is indeed what we talked about and settled on as a cross-Microsoft pattern in controls club, so I think it can be considered confirmed :)

Hosting tooltips within tooltips does not do the right thing (dismisses everything.)

"tooltips within tooltips" >>> 😱😱😱

@JustSlone
Copy link
Collaborator

Thanks @smhigley. I updated the issue above to move Tooltips do not dismiss on ctrl #14987 to "understood issues we need to fix". Can you update #14987 and confirm the intended behavior is to dismiss tooltips with ctrl.

@jurokapsiar
Copy link
Contributor

something to consider is adding aria-labelledby or aria-describedby to the trigger of the tooltip - this way devs do not have to double the information in the API and would not forget about accessibility. The downside is that if you use one or the other, you need to render tooltip content div always, not only on hover/focus. possible improvement might be to render aria-label if the text is just string. But there is no alternative like this for the description. We currently have this in v0, it would be nice to keep it, at least as optional

@JustSlone
Copy link
Collaborator

added to list of understood issues

@JustSlone JustSlone mentioned this issue Jan 14, 2021
25 tasks
@behowell behowell mentioned this issue Feb 23, 2021
34 tasks
@msft-fluent-ui-bot
Copy link
Collaborator

Because this issue has not had activity for over 150 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.

@msft-fluent-ui-bot msft-fluent-ui-bot added the Resolution: Soft Close Soft closing inactive issues over a certain period label May 24, 2021
@microsoft microsoft locked as resolved and limited conversation to collaborators Jun 24, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Component: Tooltip Resolution: Soft Close Soft closing inactive issues over a certain period Type: Epic
Projects
None yet
Development

No branches or pull requests

8 participants