Feature Request: Datalist functionality for EditText Widget (auto-complete)

[Alan Aldrich]

I considered forking TW on Github and sending a pull request, but I wanted to share this idea first, as discussion may lead to further solutions. 

One frustration I have with the current implementation of auto-completion in a text box is the inability to select from choices with the arrow keys or select the first option with the enter key. It occurred to me recently that TiddlyWiki does not utilize the HTML5 element <datalist>, but with very minimal code change it could. I propose we add a new optional parameter to the EditText Widget called "list". This simple modification will allow the user to associate a <datalist> of <options> for an auto-complete drop-down that responds to keystrokes. 

I have created a demonstration here: http://alans-sandbox.tiddlyspot.com/

More information about the datalist element: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist

I have noted some limitations of this method in the demo. The search field in the demo has also been modified to support this method, but it is not a perfect solution. I am not proposing we replace the search mechanism at this time, but I hope this thread gets people thinking about it.

Please try out my example or drag the two modified system tiddler links into your own wiki to experiment. I look forward to hearing your thoughts,

Respectfully,

Alan

[TonyM]

Alan

I support this request whole heartedly because it is a despratly needed missing feature.

I see the value in the edit text widget but also suggest also improving the existing select widget or even a new widget.

------------

However I would like to add I see a number of gaps like this between what we can do in tiddlywiki and what is available in html5. We could let this evolve and address these gaps as they are raised like this one. However I think there would be value Actualy hunting for these differences and accommodating them in tiddlywiki.

The fact is a lot of html5 features are denighed from us because we can't reference the result. This datalist method is a perfect example. You can code the html and it works except you can't access the result. This is to do with how html references the dom but not the one tiddlywiki core uses.

I believe strongly that a creative guru with tiddlywiki and dom skills could however find a way to let tiddlywiki access the result of a html operation and make it available, if only to the local wiki text. This would open many html5 features up for use in wiki text including your current datalist example. Not withstanding this I think your suggestions or versions there of, should be implemented.

Regards
Tony

[coda coder]

Would be nice but...

The options list can't be styled (or can it?)

A datalist and associated input element are associated via the id attribute. You can very easily "break the rules" by having more than one element with the same id. Think: transclude your tiddler {{DataList Feature in Edit-Text Widget}} and you have TWO copies with the same id.

I don't think there's a way to use datalist elements without an id. :/

[Mat]

If one is to manually add the select options, how does this differ from the SelectWidget?

<:-)

[Alan Aldrich]

coda coder,

Yes the id attribute is required for the datalist element to work. It must match the list attribute of the input element generated by the EditText Widget. I am requesting we modify the EditText Widget to include a parameter called list to allow the use of <datalist>. 

[Alan Aldrich]

Mat,

Not sure what you mean, input elements allow entering of text which is different from select elements that only allow you to select from a list. I am proposing we add a new parameter to the EditText Widget which will allow the user to input text, and select from a popup by utilizing a <datalist>. This can be accomplished a few ways currently, but the implementations have limitations. <datalist> is an HTML standard, and adding this functionality will enhance the EditText Widget for the reasons mentioned in the demo.

That said, the way the <option> elements work inside a <datalist> are slightly different than the way they work in a <select> element (SelectWidget). Here is some info on that: 

https://stackoverflow.com/questions/6865943/html-form-select-option-vs-datalist-option

[TonyM]

Folks, especially Alan.

See https://www.w3schools.com/jsref/dom_obj_datalist.asp in html to retrieve the value we need to use

var x = document.createElement("DATALIST");

Then also look at https://www.w3schools.com/jsref/dom_obj_details.asp

var x = document.getElementById("myDetails");

you can see that if we could use a tiddlywiki method to define or access such elements a world of html5 features would become available to us.

Tony

[Mat]

Of possible interest: https://leaverou.github.io/awesomplete/

<:-)

[Alan Aldrich]

Tony,

"...because we can't reference the result. This datalist method is a perfect example. You can code the html and it works except you can't access the result"

Am I missing something? the example in the demo works. The result is stored in a Tiddler called TestData.

[TonyM]

Alan,

Your proposal is missing nothing! Great I support it fully. 

But I was suggesting an additional more general solution. 

For example this "works" in vanilla tiddlywiki

Except you can not access the result

<select id=sresult>
  <option value="volvo">Volvo</option>
  <option value="saab">Saab</option>
  <option value="mercedes">Mercedes</option>
  <option value="audi">Audi</option>
</select>

As a result we need to use the $select widget.

Interestingly

<datalist id="testlist">
  <option value="Chrome"></option>
  <option value="Firefox">Default</option>
  <option value="Safari"></option>
  <option value="Opera"></option>
  <option value="Internet Explorer"></option>
  <option value="Microsoft Edge"></option>
</datalist>

is not even visible in tiddlywiki, unlike select/option tag.

However If we could access the result you would not even have to revert to a widget. But we should still adopt your solution.

Regards

Tony

[Alan Aldrich]

Tony,

you are correct. <datalist> itself doesnt render anything. It requires an input element with a matching "list" attribute. In fact I believe datalist element can be placed anywhere in the code, not necessarily directly under the input element. 

I just learned something else about the datalist element you may find interesting. In Chrome, you can use it on a "range" type input and it will add marks to the slider. It seems browsers vary on their implementation of the datalist element. I added a new example for this at: http://alans-sandbox.tiddlyspot.com/

[TonyM]

Alan,

Ahh I understand the need for a matching "list" attribute.

I imagine then we could put a data list for values in a tiddler that is displayed silently, or perhaps in a tiddler tagged $:/tags/Macro then access it anywhere with your proposed edit-text improvement. This is great because then multiple edit-text widgets can refer to a standard datalist to populate values.

The range type looks good, There is a range widget available already but it does not handle the example data you gave, a set of values not in a simple range.

One thing that may be important to you and may enable another hack with the datalist elements is what is already possible with the select/options tags. See here for the select widget. Note that the options are generated using the list widget so the options can be pulled from any tiddlywiki filter thus reference, title, field or variable. It would be nice if your proposed datalist could do this as well. 

On another relevant aside the edit-text widget currently permits the setting of the html type and tag https://tiddlywiki.com/#EditTextWidget

I raised this in a post some time ago see the image in the first post of  https://groups.google.com/forum/?hl=en#!searchin/tiddlywiki/html$20edit-text|sort:date/tiddlywiki/4aCyZ3FAq9U/todMTtt-AgAJ

In this post I tested all possible alternatives at the time and a number work well.

Love your work.

[coda coder]

On Wednesday, September 18, 2019 at 4:58:27 PM UTC-5, Alan Aldrich wrote:

coda coder,

Yes the id attribute is required for the datalist element to work. It must match the list attribute of the input element generated by the EditText Widget. I am requesting we modify the EditText Widget to include a parameter called list to allow the use of <datalist>. 

Yep, got that, all understood.  But I think you're missing my point. Let me try again...

When you create Tiddler A with <$edit-text id="whatever" ...> and you subsequently RE-USE that content via transclusion in Tiddler B {{Tiddler A}} then you will have broken the rules -- there will be TWO elements with id="whatever" in the document.

The id attribute MUST be unique across the document (not including any sub docs, like iframe documents).

I suspect Jeremy doesn't use ids for this very reason.

Unless you're happy creating tiddlers that cannot be used in the normal way, sorry, but this is very likely a non-starter.

The spec:  When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace. https://html.spec.whatwg.org/multipage/dom.html#the-id-attribute

MDN: The id global attribute defines an identifier (ID) which must be unique in the whole document. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/id

[Alan Aldrich]

Coda, 

Sorry, I am with you now. I didn't realize you meant "break the rules" of the HTML spec. I didn't think of that, but I agree, re-using an ID is not valid HTML. I don't know if there are exceptions to this rule for elements like datalist, but there should be. Re-using a datalist when it makes sense to seems efficient to me. A bigger issue would be the mixed browser support for the datalist element, and for these reasons I too am skeptical. I guess I would compare this to the "type" attribute. Browser support varies and not every type works perfectly, but TiddlyWiki includes it as a parameter in the EditText Widget, I suppose to support those edge cases where it works. I agree a plugin/js library would provide a more robust solution, but I am still on the fence as to whether adding this param makes sense. I really think this functionality (using arrow keys and enter key to choose an auto-complete option)  should exist as a core feature, not a bolt-on. In any case, I am tired of picking up my mouse when I search for something in TiddlyWiki.

[Mohammad]

Hi Alan,

 This is great idea! I even encourage some other html5 should be added to the core!

It may possible to use selectwidget + edittextwidget now but why not to use the more semantic and clear datalist?

I support your idea!

--Mohammad

[Mohammad]

Hi Alan,

The `id` attribute is not a good idea and I am sure it will be rejected!

If you need a separate datalist with id then they will say use the currect selectwidget!

One idea may be to use <$edit-text> list goes here </$edit-text>

It should have a simple syntax!

--Mohammad

[coda coder]

On Wednesday, September 18, 2019 at 10:11:10 PM UTC-5, Alan Aldrich wrote:

I don't know if there are exceptions to this rule for elements like datalist, but there should be.

They should have used --id or similar. (data-id would tread on author territory so that's no good).

 

Re-using a datalist when it makes sense to seems efficient to me.

Yep. I got into a tussle with one of the spec writers over some of the wording around datalist and options -- forgotten the exact details it's been so long, but it was some inconsistency that bugged the hell outta me.

 

I really think this functionality (using arrow keys and enter key to choose an auto-complete option)  should exist as a core feature, not a bolt-on. In any case, I am tired of picking up my mouse when I search for something in TiddlyWiki.

+1 x 1000

 

[TonyM]

Mohammad,

You are correct the The content of the <$edit-text> widget is ignored. So if it could supply wikitext interpreted as the data list perhaps we just extend the edit-text widget. However people may instinctively look in the select widget for this functionality as well.

Good idea.

Tony

[Alan Aldrich]

I appreciate everyone's feedback on this topic. I think we all agree on the goal, but we have yet to find the perfect solution. The ultimate goal here is to create a better auto-complete dropdown for the search field that responds to keystrokes, and some of the proposed solutions include extending the functionality of an existing widget like EditText or Select or going with a JS plugin like Awesomplete. 

There is one more requirement for this feature, and potential challenge that I hope we can discuss. 

The datalist element can utilize the list widget to generate a list of options (similar to the select widget options). This is how the modified search field on my demo works. However, the only options that appear as the user enters text are titles that contain the text being typed. The real requirement is to generate a dropdown of choices that are titles of tiddlers where either the title, tags or text contains the text being typed. That is how the current search works. This is a limitation of the datalist option. That is, even if you generate a list of options using the search filter, the option has to match some text being entered in order to be visible. That is the way auto-complete usually works. If you dig into the documentation for https://leaverou.github.io/awesomplete/ you will see that this option will have the same problem. You can specify a list based on the search filter (theoretically) but it will only display a subset of that list based on what the user types. 

Hopefully I am explaining this clearly. What this means to me is we will likely need a customized solution. Perhaps we need to expand on the existing functionality. I believe this to be the recommended way to create an auto-complete list on a textbox today:

from Jeremy: [TW5] edit-text widget with popup

<$edit-text tiddler="TargetTiddler" tag="input" default="" focusPopup="$:/state/demo" class="tc-popup-handle"/>
<$reveal state="$:/state/demo" type="nomatch" text="" default="">
<div class="tc-block-dropdown">
<$linkcatcher to="TargetTiddler">
<div class="tc-dropdown-item">
[[A value to set]]
[[Another value]]
[[These links could be generated]]
[[by a list widget, too]]
</div>
</$linkcatcher>
</div>
</$reveal>

The part that is missing is that the popup does not respond to keystrokes. That is the real issue. It would be a shame to roll out a new auto-complete feature that doesn't work as expected when "searching" fields other than title.

[coda coder]

On Thursday, September 19, 2019 at 3:44:02 PM UTC-5, Alan Aldrich wrote:

Hopefully I am explaining this clearly.

Well, I'm following it ;)

 

What this means to me is we will likely need a customized solution.

I think so. In js, you could rebuild the datalist "live" as the input changes, but that's still not how you envisage it working. I really don't think datalist is the way to go (the id problem, as I said, is a non-starter, I believe).

Perhaps the popup mechanism can be enhanced to support correct tabbing/keyboard behavior? Although, I do imagine with some heavyweight TWs, that might prove slow.

[Alan Aldrich]

I agree coda, I think enhancing the popup mechanism is the way to go. I am no longer recommending we add functionality for <datalist> for many reasons. Even if the id issue didn't exist it still wouldn't work for the search field. Should we start a new topic with a clearer agenda? 

[TonyM]

Alan,

Happy to follow your lead on this. Some thoughts you may not have considered?

• If the text that is used to search and or autocomplete is in a state tiddler or field, more than one widget can access it at a time. What if we simply place a search result popup along side your existing auto complete example. That is the designer crafts the desired result from a suitable combination of widgets existing or tweaked to support this?
• There are always benefits to be had from maintaining modularity because as yet unconsidered combinations become available and prove to be useful.
• The current $select widget is a widget even although it may leverage the html select so it seems to me to extend it to accommodate autocomplete may be the most profitable. Especially if the use of the edit-text widget within it is not extended. As I suggested previously you can for example use the edit-text input/tag options to only accept numbers in the edit field, this has value that may be lost it edit text if modified?

Regards

Tony