Bug #7645
closedInconsistencies with anchor text selection and inclusion in tab chain
100%
Description
As of github wt 4.3.0-42-g6d15a8a7, there are two minor inconsistencies with anchors related to whether the anchor text is selectable and whether the anchor is reachable in the tab chain.
This issue has been in Wt for a while and can be observed with the widgetgallery example. First, visit the internal path "widgets/navigation/menu" and then click on the "Tab widget" item on the left-hand menu. The text within the Example tabs ("First", "Preload", "Style", "Close") is selectable and the four example tabs are not included in the tab chain as you tab through the screen.
If you refresh the page, the behavior of the Example tabs transitions to what I believe is more correct behavior: the anchor text within each tab will no longer be selectable and the four example tabs will be included in the tab chain.
The difference between the two tab behaviors is due to the progressive bootstrap that occurs with the refresh. With a progressive bootstrap, the anchors for the tabs receive href attributes as well as click handlers. When the page is reached in other ways, there are no href attributes on these tab anchors and that is why they are not included in the tab chain by default. Likewise, the anchor text becomes selectable because that is the default behavior unless it is draggable, and an anchor is not draggable without an href attribute.
From my perspective, the primary concern is the selectability of anchor text. The selection of a few characters looks odd if a user accidentally moves the mouse while attempting to click on a tab and it also replaces the user's selection buffer, which may cause confusion.
Attached, for your review, is a lightly tested patch that adds href attributes to anchors with the goal of providing more consistent behavior with tab order and selectability of anchor text. There are additional comments on the patch.
As an alternative, Mozilla advises using button elements rather than anchors that only have click handlers (see: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a), but I suspect that approach would take far more work to implement and present compatibility issues with the Bootstrap styling. Another possibility is to incorporate CSS "user-select: none" rules to address the selectable anchor text issue, but that would not address the tab chain issue.
Files
Updated by Bruce Toll over 4 years ago
I did some additional testing and found a problem with the patch breaking existing code. Specifically, I had a WMenu in a WDialog where it was intended that focus would remain in the WDialog using keyWentDown() to check for arrow keys and switch between menu entries. With the patch, the arrow keys continue to work --- until you click on a menu item. At that point, focus switches and the arrow keys in the parent WDialog no longer respond (but the tab key now does). In any case, the existing code depended on the fact that the menu items could not receive focus (even with a click) and the patch broke that assumption. I suspect this is just one example of the patch having too broad an effect.
So, I'd suggest ignoring the patch in its current state --- although I'm open to any feedback on improving it. In the meantime, I think that using CSS "user-select:none" will provide a more targeted approach to preventing anchor text from being selected and it can be implemented outside the library in user code.
Updated by Roel Standaert almost 4 years ago
- Description updated (diff)
- Target version changed from 4.5.0 to 4.6.0
Updated by Roel Standaert over 3 years ago
- Target version changed from 4.6.0 to future
Updated by Roel Standaert almost 3 years ago
- Target version changed from future to 4.7.0
Updated by Korneel Dumon almost 3 years ago
I did some testing with having WAnchor
render as a <button>
when it has no link. For the styling, I added btn btn-link
. In bootstrap 3 this looks similar but not quite there since the style sheets rely on the <a>
tag in the context of these navigation buttons. In bootstrap 5, it works nicely since they rely on style class nav-link
.
Apart from the bootstrap 3 issue, I also found it conceptually a bit weird to render WAnchor
as <button>
(it is also documented to render as <a>
). For these reasons, I am putting this issue aside for now.
Updated by Roel Standaert over 2 years ago
- Target version changed from 4.7.0 to 4.8.0
Updated by Roel Standaert over 2 years ago
- Target version changed from 4.8.0 to 4.9.0
Updated by Roel Standaert about 2 years ago
- Target version changed from 4.9.0 to 4.10.0
Updated by Matthias Van Ceulebroeck over 1 year ago
- Target version changed from 4.10.0 to 4.10.1
Updated by Matthias Van Ceulebroeck over 1 year ago
- Status changed from New to InProgress
- Assignee set to Matthias Van Ceulebroeck
Updated by Matthias Van Ceulebroeck over 1 year ago
- Status changed from InProgress to Review
It seems correct to implement this without changing the WAnchor
to a <button>
, and by setting the href
attribute to javascript:void(0);
. The breaking of the tab chain in a dialog to me seems expected. The focus changes to a specific item, and as such the handler for another item should not catch the items if the focus changed. Navigating with "tab" seems more correct here.
Updated by Matthias Van Ceulebroeck over 1 year ago
- Assignee deleted (
Matthias Van Ceulebroeck)
Updated by Matthias Van Ceulebroeck over 1 year ago
- Assignee set to Korneel Dumon
Updated by Korneel Dumon over 1 year ago
- Status changed from Review to Implemented @Emweb
- Assignee changed from Korneel Dumon to Matthias Van Ceulebroeck
Updated by Matthias Van Ceulebroeck over 1 year ago
- % Done changed from 0 to 100
Updated by Matthias Van Ceulebroeck about 1 year ago
- Status changed from Implemented @Emweb to Closed