Inconsistencies with anchor text selection and inclusion in tab chain
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.
Updated by Bruce Toll over 2 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 Korneel Dumon 12 months 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
Apart from the bootstrap 3 issue, I also found it conceptually a bit weird to render
<button> (it is also documented to render as
<a>). For these reasons, I am putting this issue aside for now.