refactor(tooltip): Use pointer events in favor of mouse events

[driskull]

Related Issue: #5318

Summary

refactor(tooltip): Use pointer events in favor of mouse events. (#5318)

pointer events will fire on disabled elements.

[driskull]

@jcfranco I think these code changes make sense. However, because we disable pointer events on our disabled elements the tooltips will still not show. This does fix the issue for disabled native buttons though.

@jcfranco Do you think we should try and support tooltips on our disabled elements?

[jcfranco]

Do you think we should try and support tooltips on our disabled elements?

@darrenDoesntCode @ashetland @SkyeSeitz @geospatialem WDYT?

[ashetland]

Do you think we should try and support tooltips on our disabled elements?

@darrenDoesntCode @ashetland @SkyeSeitz @geospatialem WDYT?

Definitely useful, especially if the tooltip can tell me why it's disabled.

[macandcheese]

Hm, I'm not sure I would expect a disabled component to be interactive at all. I might expect another, not disabled UI element to invoke the tooltip. There are likely screenreader implications here to consider.

[geospatialem]

Tested with NVDA and JAWS, and the disabled context isn't provided to them, which is the expectation with assistive technology.

However, if implemented, this might be a case where we're providing content to some users, but not all. Not ideal to accommodate a larger audience.

As Adam mentioned there could be another, non-disabled UI element that could invoke the tooltip for these use cases instead.

[driskull]

The native button and native tooltip still work when the button is disabled.

https://codepen.io/driskull/pen/yLjVWVK?editors=1000

[geospatialem]

The native button and native tooltip still work when the button is disabled.

Ah, thanks for the context! If that's the native behavior, then makes sense to proceed. 👍🏻

[ashetland]

The native button and native tooltip still work when the button is disabled.

https://codepen.io/driskull/pen/yLjVWVK?editors=1000

I knew I had seen this somewhere!

[macandcheese]

I still am not sure the tooltip should be invoked. Sometimes tooltips are just the name of button / action, but they are also used to contain descriptive or supplementary text, and only making that available via hover (and not focus, or click) seems weird.

I think it’s valid to maintain the native functionality of showing a label on hover, but to me a label and tooltip are not totally the same.

[jcfranco]

I think it’s valid to maintain the native functionality of showing a label on hover, but to me a label and tooltip are not totally the same.

@macandcheese Agreed, but that sounds like that will be up to the developers since we wouldn't use title + calcite-tooltip (a), but rather just calcite-tooltips for both use cases (b), right? If we're all in agreement w/ b, this PR is good to go!

BTW, I'm assuming you used label to mean native tooltip, but please correct me if you meant something else.

[driskull]

I think this PR is good to go regardless as it just changes from mouse to pointer events.

If we want to remove the pointer-events:none on our disabled calcite-button that would be the part that allows our tooltips on our disabled buttons.

[jcfranco]

Good point. Moving forward!

WRT allowing tooltips on disabled components, let me know if y'all prefer an issue or discussion.

[jcfranco]

🐭👈