We need to implement the datalist element in FAPI, and hopefully Field API as well. In #1512194: Use HTML5 datalists for autocomplete, it was suggested this be broken out into a separate issue as that issue focuses more on updating our autocomplete implementation, and there are concerns regarding accessibility and dynamic needs (putting really large datasets in markup won't fly) that go along with that.
However, this element, which works like an autocomplete list in the browsers that support it, doesn't necessarily need to be paired 1:1 with our autocomplete implementation. It doesn't need to be dynamic, it won't always be a huge dataset and there is a perfectly reasonable way to implement it in a way that degrades gracefully in browsers that don't support it.
Quote from Comment #14:
According to HTML5 Please, it is recommended as safe to use: http://html5please.com/#<datalist>
One of the options there, instead of directly tying it to our autocomplete widget and having to polyfill it, is to output it is a
<select>
list inside the<datalist>
element. Jeremy Keith wrote a post about it. If you look at this in Firefox vs. Chrome, it's actually quite elegant:
Check out the example yourself.The code looks like this:
<form> <label for="source">How did you hear about us?</label> <datalist id="sources"> <select name="source"> <option>please choose...</option> <option value="television">Television</option> <option value="radio">Radio</option> <option value="newspaper">Newspaper</option> <option>Other</option> </select> If other, please specify: </datalist> <input id="source" name="source" list="sources"> <input type="submit"> </form>
Personally, I think this could be a good option for Drupal. It could be implemented as an option for "list" fields, completely separate from the current autocomplete functionality. This also would eliminate the large dataset issue. So... it's not exactly what's being proposed in this issue, and it would likely require adding Select (or other) functionality to core, but it's pretty useful, and requires zero JavaScript, so I think it's an option worth considering.
Comments
Comment #1
JacineOne of the concerns brought up in #1512194-15: Use HTML5 datalists for autocomplete is theming:
IMO, I don't think this is an issue. In Drupal we set all
<label>
elements todisplay: block;
with CSS by default, so the horizontal space isn't really an issue. The fields will just stack, and we can add basic default styling for it, if needed.Comment #2
tim.plunkettRecategorizing.
Comment #3
KarenS CreditAttribution: KarenS commentedI just ran into this issue myself. In my case, I'm working on displaying date parts using the html5 'number' type (the recommended treatment for historical dates). The only thing needed for this to be a complete solution is that the numbers need to show up as a select list in older browsers -- a blank textfield is absolutely not a solution. It looks like the fix is quite simple and should be generally useful. Just alter the current select theme to prefix and suffix it with a datalist, like this:
That should create no problems for older browsers but makes the select list act as a datalist for newer ones. The one problem is that webkit browsers get it wrong. And it turns out that can be fixed with a tiny css tweak:
I found this idea at http://adactio.com/journal/4272/, I can't take credit for thinking of it.
So I propose we just make this change to the core select theme. To take advantage of it, modules will need to pass in the right attributes (like give the select element a 'number' type), but at least core is not standing in the way of making it usable.
Comment #4
Crell CreditAttribution: Crell commentedI don't think a blanket change of select to datalist is what we're discussing. Restricted select still has a zillion use cases. Datalist-backed options should be their own form element.
Comment #5
KarenS CreditAttribution: KarenS commentedAs far as I can see, wrapping this in a datalist has no downside if you don't want the datalist, so it can work for either use case. We can create a different element if that's what people want, but I don't see the point.
Comment #6
KarenS CreditAttribution: KarenS commentedOK, I found this won't work for the problem I was trying to solve. According to the specs, you can use datalist together with a number element, which should have allowed me to create numeric drop-down list of months, days, years that still have the user-friendly labels. But it doesn't appear that they work together that way at all, nor can I find any method that seems to work to define a datalist that can be used for a number element no matter how I try to combine them.
So the main use for this is probably back to the autocomplete, which does seem to work. And I haven't tested it as an autocomplete, so I don't know whether or not we have to do something else to get it working. But if it does require more messing around, it probably would be better as its own element.
Comment #7
nod_Looking at this as a possible way of doing token search in core #514990: Add a UI for browsing tokens. It actually fits well with how it could be done, think rules ui selection style.
Comment #8
jhedstromReferenced issue is now 8.1, moving this one as well.
Comment #15
nod_Things have improved on the datalist front, it's more usable now (especially chrome). I say we can try again?
Comment #25
AnybodyJust came across this and was wondering why it's still required to use a contrib module for datalist: https://www.drupal.org/project/datalist
I think it would still make a lot of sense to have this available in core. So should we perhaps base this issues MR on that contrib module?
datalist is supported by all major browsers: https://caniuse.com/datalist
Many people (at least I think so) will decide against adding a contrib module as additional dependency for this functionality. So I think this, now basic and common, HTML element should be available in Core FAPI.
How should we proceed here?
Comment #26
Sweetchuck@AnyBody I think that contrib module implements the required functionality in a wrong way.
datalist != textfield
Comment #27
Anybody@Sweetchuck I disagree.
See
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist#textu...
and
$element['#attributes']['type'] = 'text';
is totally fine from my perspective and matches the fallback value (like if no type was set).
Still datalists can also be used on other types, as written in the docs. So for core we could also add this as an extension to other field types.
But of course further improvements to the current contrib implementation can be discussed (already in the modules issues).
Would be great to have some more feedback here, how that's expected. Perhaps it should be a core contrib module, like telephone and others? (But definitely in core as W3C standard representation)
Comment #28
SweetchuckWith that implementation how can you re-use the same datalist for multiple textfields?
Comment #29
Sweetchuckdatalist also can be used for "range" inputs
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist#range...