Implement persistent text label without tooltip

[hashwin]

Followup from the conversation in #12856

Since the tooltip appearing and disappearing based on mouse movements is not required at all for this case, use of the tooltip can be avoided.

@oliviertassinari

[mbrookes]

Okay, thanks @hashwin. In that case lets look to unify the styling, if not in this PR then a separate one.

[hashwin]

@mbrookes Seems like the behavior specified by material design is not to use tooltips when hovering over, rather use extended FABs as specified here: https://material.io/design/components/buttons-floating-action-button.html#extended-fab

But that seems like it's independent of this feature, so I would leave that for a different PR.

[oliviertassinari]

I need to understand the issue first. What do you mean "behind"?

@eps1lon Let's say you are using a Windows surface (large screen) and a media query based logic to change the tooltip style, you might miss the information displayed when using a long touch to display the tooltip.

[eps1lon]

I need to understand the issue first. What do you mean "behind"?

@eps1lon Let's say you are using a Window surface (large screen) and a media query based logic to change the tooltip style, you might miss the information displayed when using a long touch to display the tooltip.

@oliviertassinari Can you link me some sites that have the same behavior? I have pretty big hands/fingers and I can still see that something popped up after a touch. How do you determine where the tootip would not be hidden behind the users finger? If I reach from the right and the placement is below nothing has to change. If I reach from the right and the placement is right I might not see it (as you said).

[oliviertassinari]

Can you link me some sites that have the same behavior?

@eps1lon Not I'm aware off. It's really about an interpretation of the specification, in a gray area. My point is that it should be touch/mouse based, it's better than a screen size based logic. It's what I believe provide a better UX.

[hashwin]

FWIW I have had this branch running in my production app, and my users have reported that all the issues (hybrid device clicks, glitchy tooltip size, positioning and click behavior) have all been resolved.

[mbrookes]

Maybe the answer to the problem is really simple. Why do we override the CSS to always looks like

I think perhaps you meant "why don't we"? In that case, I agree - it solves the problem (even if those big-ass tooltips are a bit ugly).

[hashwin]

@oliviertassinari @mbrookes @eps1lon Apologies, I haven't followed up on this, just wanted to check, was there any consensus on this? As I mentioned I have been using this branch AS IS on my production app and have had absolutely no problems.

[mbrookes]

At this stage, given no further feedback, I'd suggest that merging this is better than the alternative.

Last call for comments @mui-org/core-contributors; otherwise, @hashwin if you could fix up the couple of code concerns that @eps1lon raised, and resolve the merge conflicts...

[mbrookes]

@hashwin Are you happy to wrap this up?

[hashwin]

@mbrookes Sure I will try to clean this up this weekend

[hashwin]

@mbrookes I updated the branch, getting a regression failure with a screenshot, not sure how to fix it.

[mbrookes]

@hashwin I have changed the target branch to next, as master is now only for bug fixes, but I'm afraid that means you will have to rebase again, sorry. After that I can accept the visual regression.

[oliviertassinari]

I'm closing, feel free to continue the effort :)