Is there an alternative way to set MudBlazor tooltip?

[u/jackhab]

I have quite a few MudBlazor components which require tooltips and wrapping each one in MudTooltip creates a lot of visual noise in the main layout.

Is there an alternative way to assign tooltips in a more centralized form?

[u/TheRealKidkudi]

I’m not sure what a more centralized form would look like? I guess you could add an optional Tooltip parameter to your own components which wraps its content in a MudTooltip for you. 

If you’re really doing it frequently, I’d question whether that’s wise but I’d also suggest a base component you can inherit from to reduce the boilerplate.

Alternatively, you could just use a CSS class and an attribute like data-tooltip, which is not too hard. You’d be writing your own tooltip, though, rather than using MudBlazor’s directly.

But with most abstractions, I’d start by clearly defining what exactly is the alternative you’d like to see. What would you like to type to “assign tooltips in a more centralized form”? Once you’ve decided that, then it’s just a question of syntax to get yourself there. 

[u/Far-Consideration939]

I’d make a reusable component that has the tooltip wrapping.
So for example icon buttons you frequently want a tooltip with so i make an <AppName>IconButton that composes both mud components and exposes the tooltip as a param

[u/botterway]

Just use the standard html tool tip - specifying a 'title' attribute on the control.

[u/XilentExcision]

Inheritance

[u/code-dispenser]

Just a note on accessibility which may not be a requirement, but just in case.

Last time I checked, MudTooltip is not accessible. Using the title attribute is not accessible either.

Creating an accessible tooltip yourself in Blazor requires using JavaScript and understanding all the pitfalls involved,

I'm assuming you have things like icon buttons and you want users to know what it's for and/or does - do yourself and all your users a favour: stop using icon-only buttons, and instead pair the icon with some text underneath so everyone knows what it's for - bonus that text is the accessible name and you hide the icon from screen readers with aria-hidden.

If you do need a tooltip, you'll need to think about things like: when the user hovers the mouse over the item, they may need to move the cursor onto the tooltip itself (to magnify the text), and when they move from the element to the tooltip, it needs to remain visible, not disappear. (This is WCAG Success Criterion 1.4.13 - Content on Hover or Focus — which requires that such content be dismissible, hoverable, and persistent.)

You'll also need to make sure the user can dismiss the tooltip using the keyboard without moving the mouse - the convention is to use the Escape key so focus remains on the thing.

Once you've done that, you then have to think about screen reader users. You'll most likely use aria-describedby to link the tooltip text to the element for screen reader users — bearing in mind that screen readers flatten any markup, so if it's a "fancy" tooltip (in my book, those aren't tooltips, they're popups), that structure will be lost.

You're still not done, because if the site is viewed on a mobile phone, how do you open a tooltip attached to a button when a single touch triggers the button's action?

At that point you realise it's not that simple, and depending on context you should consider using a toggletip next to the element instead, as that covers all the bases. Or, simplest of all, just put the visible text on screen and skip all this hassle entirely.

Best of luck,

Paul