Setting the proper tab index of a custom field editor

#1

I managed to follow the instructions at Customizing EditTemplate field rendering to use a <$select ...> widget as an editor for one of my fields.

Everything seems to work fine except the tab index.

When tabbing through the field entries, it skips over my new <select> and goes on to the next field. If I have patience, I can continue to tab and get through the fields, the sidebar, the tiddler toolbar, all the editor toolbar buttons, the remove-field buttons for the preceding fields and finally my widget. Then it continues to the succeeding remove-field buttons. That kind of patience is a virtue I don’t want! :wink:

Riffing on $:/core/ui/EditTemplate/fieldEditor/default I added tabindex={{$:/config/EditTabIndex}} to the widget, but it made no difference.

You can see this in action by downloading the following and dragging it to a wiki, then clicking on the added toolbar button (“Create a new Document Link”) and tabbing through the field entry section.

SelectFieldEditor.json (2.6 KB)

Any suggestions on how I can fix this?

#2

I did this recently and dont recall an issue with the tabbing. Hopefuly I will share it soon.
[Edit] I found my solution (note to self, in Blogs) but it is not tabbing correctly.

#3

Thank you very much for checking!

#4

The final select element doesn’t contain tabindex attribute and its value, the reason is because the $select widget doesn’t have this attribute.

#5

Oh wow, you’re quite right. That sounds like a bug!

Are there any known work-arounds? Perhaps some way to pass HTML attributes through the widget invocation?

#6

I don’t know it. The only way to do it would be to modify the widget, but I’m not sure if it could be done with the \widget pragma and/or $genesis widget. It would be the only alternative to hack the tiddler of the $select widget ( $:/core/modules/widgets/select.js) that I think.

#7

At the very least a feature request (IDEA in TW GitHub parlance).

1 Like
#8

And maybe small enough for me to take on and try my first PR in this project! I’ll see what I can do this weekend.

#9
  • It may not need it
  • Why pass it in to code when you can wrap it?

I did not have time to respond when this first came up, and now I am ill, and not got a lot of energy. But I suggest concider opening your mind to what we can do than focus on what you cant. If I were feeling better I may work though the problem but to help concider;

  • Html tags such as span and div, and the CSS that can be applied to them, can be interoduced easily to Wikitext and TiddlyWiki script.
  • Perhaps try a widget that does set the tab index, use browser inspect or the internals plugin html view, to see what is generated, then apply this around your select widget.
#10

I’m sorry to hear that and I hope you feel better soon!

I did consider that and didn’t bother trying because I was pretty sure it wouldn’t work – setting the focus on the wrapper will not focus on the <select ...> control. But I have now tried it and as I suspected, it tabs in the correct order, but focuses on the wrapper and not the control, which doesn’t help with keyboard navigation and editing.

Working correctly, when I tab into a <select ...>, I can then use the up- and down-arrows to choose from the options. But it’s not working correctly here; when I wrap the widget with <span tabindex="1"> ... </span>, it looks right, and I tab to it in the right order, but then the arrow keys are shifting the whole page. I’ve focused on the <span> and not on the <select>.

This definitely feels like a TW bug, and I will try tomorrow to create a pull request with a fix. At that point, we’ll see if the maintainers agree.

#11

The new 5.3.0 May allow you to make a custom widget or redefine the core one to resolve this in the mean time, the select widget is after all a tw invocation of the html select.

#12

Well yes, and the HTML <select ...> element has a tabindex attribute. It simply looks as though the TW <$select ...> widget does not pass it along.

#13

Unless there are good reasons not to do so, I would suggest that a future release of TW should make all HTML widgets support (i.e. pass through untouched) all available HTML attrs.

@jeremyruston ?

1 Like
#14

I think that idea has merit, however given 5.3.0’s ability to redefine core widgets you may be able to do this yourself. There may be a few places where attributes clash and a naming standard may be needed.

  • I have argued for this “html parameter passthrough” in the past to help users customise widgets and reduce the load on the developers to add parameters to widgets, thus javascript changes and addressing backwards compatibility issues.
  • If we can build a generic solution it would be quite powerful but only the core development team @jeremyruston are in a position to implement this safely.
    • Or though we could implement workarounds.
    • Such a generic solution may reduce the need for future core widget changes.
  • Perhaps there is a way to set such html attibutes outside the widget, such that the html generated inside the widget “inherits” them. This is possible in CSS if there are appropriate css selectors involved. But I am no CSS expert.
#15

@TW_Tones, are you sure about we can redefine core widgets to add new attributes? Because in the example I don’t see how add a new attribute. The redefine core widget use the genesis widget.

I tried to create a new widget for this case but I was not able to get the attribute to be added.

\widget $my.select(tabindex:"0")
<$genesis $type="$select" tiddler="test" class="tc-edit-texteditor tc-edit-fieldeditor" tabindex=<<tabindex>> cancelPopups="yes">
    <$list filter='A B C'>
        <option value=<<currentTiddler>>><$view field='title'/></option>
    </$list>
</$genesis>
\end

<$my.select tabindex={{$:/config/EditTabIndex}}/>

Maybe I did something wrong. I don’t know.

It would be great.

#16

I created a pull request for this: Add `tabindex` to SelectWidget and docs by CrossEye · Pull Request #7594 · Jermolene/TiddlyWiki5 · GitHub.

1 Like
#17

I took this as really meaning that we should override the actual widget. It does work:

SelectWidget.json (6.2 KB)

I added the middle line here:

	this.selectSize = this.getAttribute("size");
	this.selectTabindex = this.getAttribute("tabindex");
	this.selectTooltip = this.getAttribute("tooltip");

and this little section:

	if(this.selectTabindex) {
		$tw.utils.addAttributeToParseTreeNode(selectNode,"tabindex",this.selectTabindex);
	}

alongside other similar sections. You will have to save and reload to use this, since it’s JS code.

2 Likes
#18

If you look at the new features it seems you can, and I belive it has being said previously. I am still educating myself on the changes.

#19

Yes, but what is the meaning of

to customise their behaviour.

I doubt about it. Then I did my try, but my code didn’t and I don’t know if I fail or the customization does not reach that level.

#20

For example the link widget can be used in wiki script but the core also uses its for cAmel Case and [[tiddler links]] so you can add now redefine the link widget to add additional features. See recent discussions about the link widget.

I am not skilled enough to guide you yet.