Fix: Tabs switch on mousedown and checks for defaultPrevented

[scomea]

Tabs should select on mousedown rather than click, this seems typical and makes implementing draggable tabs easier in that the tab being dragged should be the selected one so selection should happen before mouseup.

Addtionally, added checks for defaultPrevented in the event handlers. Tabs can have things like clickable close buttons that may want to block default handling.

🎫 Issues

Ad-hoc. Stuff I'm noticing while implementing.

✅ Checklist

General

• I have included a change request file using $ yarn change
• I have added tests for my changes.
• I have tested my changes.
• I have updated the project documentation to reflect my changes.
• I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

• I have added a new component
• I have modified an existing component
• I have updated the definition file
• I have updated the configuration file

[bheston]

I checked about 80 examples from various design systems and found only 6 which switched on mouse down instead of click. I don't disagree with the behavior, but it appears it's not the most common interaction.

I wonder if there could be performance implications, like if a tab loaded content only when it was displayed. Unlikely edge case, but having the interaction on click allows someone to not complete the click by moving away before releasing - if the tabs are not draggable anyway.

In the case of draggable tabs it seems possible I might want to reorder tabs without needing to switch to them. I do this in the browser sometimes where I want to organize a bit but I don't actually need each tab to load again.

I also wonder if this implies that other components should have behavior on mouse down instead of click, like maybe an Accordion.

Curious to hear other's thoughts. I don't feel strongly either way.

[bheston]

Came across the wcag requirements for pointer cancellation: https://www.w3.org/TR/WCAG21/#pointer-cancellation which might apply here.

Is it possible to support dragging to reorder tabs without them being selected?

[scomea]

Came across the wcag requirements for pointer cancellation: https://www.w3.org/TR/WCAG21/#pointer-cancellation which might apply here.

Is it possible to support dragging to reorder tabs without them being selected?

My "model" was the way browser tabs on Edge work (ie. select on mousedown, you're dragging the selected tab) as that seemed a reasonable approach. Happy to look at other approaches. I'm not committed to any particular mechanic.

[scomea]

All the browsers look to have the "select on mousedown" behavior, as does VSCode. It seems like a reasonable design decision either way. If we're not planning on implementing drag and drop maybe the right approach would be to make it easy to extend the component to implement either? ie. protected functions and or by wiring up the template differently.

[bheston]

All the browsers look to have the "select on mousedown" behavior, as does VSCode. It seems like a reasonable design decision either way. If we're not planning on implementing drag and drop maybe the right approach would be to make it easy to extend the component to implement either? ie. protected functions and or by wiring up the template differently.

I'm on board with that. There have been a few other similar changes recently. The default case here is not to have drag and drop, so to align with a11y best practices I like the idea of leaving the cancel capability. I still think drag could happen without a tab becoming selected, but it might not always make sense.