Implement rich button tooltips with keystroke information

[oleq]

A followup of #29.

Related issue: #58.

---

#29 implements tooltips using the title attribute, but they're not very pretty. They could look like this instead:

I wonder if pure CSS solution is enough here using ::after/::before pseudo–elements and content: attr(title) definition. This approach feels a way more lightweight than any JS solution and lets us postpone BalloonPanel refactoring, which is a good news 😄 .

[oleq]

A random example from the web http://cssdeck.com/labs/pure-css-tooltip-with-arrow.

[fredck]

The only problem with the CSS only approach is that the title attribute still has its UI behavior, which duplicates the tooltip.

Also, being it a balloon, wouldn't it be nicer to have it at the top of the button?

[fredck]

The only problem with the CSS only approach is that the title attribute still has its UI behavior, which duplicates the tooltip.

I the other hand, I was wondering if we really need the title attribute here or we can instead use aria attributes for the a11y requirements. It seems to be the way to go.

[fredck]

In fact, I've just updated the above example, replacing title with aria-label and it works like a charm.

[oleq]

Also, being it a balloon, wouldn't it be nicer to have it at the top of the button?

Why not. TBH I haven't done any UX research yet about such stuff.

In fact, I've just updated the above example, replacing title with aria-label and it works like a charm.

👍

[Reinmar]

Important question in this topic. Do we want to be able to display rich info in those tooltips? By rich, I mean enhanced with HTML+CSS.

In the buttons case when we only need to display the title and the keystroke it doesn't sound like something crucial, though it would be nice to mark the keystroke with a bit different color e.g.

However, if we'll ever plan to display some bigger infos, then we'd need enhanced tooltips. And I think that if we go with pure CSS now, then in the future we may need a more advanced solution anyway, duplicating a bit what we have. This should be transparent for the users of the button component, even if we change the tooltip type, but perhaps it's worth consideration.

OTOH, a CSS approach is a couple of hours of work max, while a new component is ~2 days. So perhaps this is the answer.

[fredck]

Sounds like overengineering. Let's keep it simple and efficient, as proposed. I doubt more than that will bring effective value. Anyway, having this discussed here is not a bad thing.

[pjasiun]

It might be useful to be able to tell where tooltip should be shown: above, below, on the left or on the right. For instance for the inline toolbar, if the toolbar is above the text, not to hide the content, we may consider showing tooltip above the button as well. Or if we will have a horizontal menu tooltips should not hide other buttons and should be next to them.

[oleq]

The very first problem with a pure :after/:before solution: the tooltip remains when hovered, making the content beneath inaccessible:

[Reinmar]

:(

[oleq]

It could work if we move it a couple of px off the button, but... not always.

[Comandeer]

That issue could be resolved using pointer-events: none → https://jsfiddle.net/h63Lbpth/

[Reinmar]

LOL, I thought about it but I thought that it only affects JS events :D. @Comandeer for the rescue!

[oleq]

@Comandeer You're the Gandalf.