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:

Screenshot of Datalast with select fallback in Firefox (supported) and Chrome (not supported)
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

Jacine’s picture

One of the concerns brought up in #1512194-15: Use HTML5 datalists for autocomplete is theming:

The fallback and supported versions are quite different, visually. My biggest concern is it makes theming substantially harder, because the horizontal space of supported and non-supported browsers substantially different. Not being a themer I don't know how much of an issue that is in practice, but it's a concern.

IMO, I don't think this is an issue. In Drupal we set all <label> elements to display: 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.

tim.plunkett’s picture

Category: task » feature

Recategorizing.

KarenS’s picture

I 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:

 */
function theme_select($variables) {
  $element = $variables['element'];
  element_set_attributes($element, array('id', 'name', 'size'));
  _form_set_class($element, array('form-select'));

  return '<datalist id="' . $element['#id'] . '"> <select' . new Attribute($element['#attributes']) . '>' . form_select_options($element) . '</select> </datalist>';

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:

datalist {
  display: inline-block;
}

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.

Crell’s picture

I 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.

KarenS’s picture

As 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.

KarenS’s picture

OK, 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.

nod_’s picture

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.

jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev

Referenced issue is now 8.1, moving this one as well.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

nod_’s picture

Things have improved on the datalist front, it's more usable now (especially chrome). I say we can try again?

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Anybody’s picture

Just 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?

Sweetchuck’s picture

@AnyBody I think that contrib module implements the required functionality in a wrong way.

datalist != textfield

  1. https://git.drupalcode.org/project/datalist/-/blob/1.0.x/src/Element/Dat...
  2. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist
Anybody’s picture

@Sweetchuck I disagree.

See
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist#textu...

Recommended values in types text, search, url, tel, email and number, are displayed in a drop-down menu when user clicks or double-clicks on the control.

and

Note: When type is not supported, text type creating simple text field will be used instead. That field will correctly recognize recommended values and display them to the user in a drop-down menu.

$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)

Sweetchuck’s picture

With that implementation how can you re-use the same datalist for multiple textfields?

Sweetchuck’s picture

datalist also can be used for "range" inputs

<label for="tick">Tip amount:</label>
<input type="range" list="tickmarks" min="0" max="100" id="tick" name="tick" />
<datalist id="tickmarks">
  <option value="0"></option>
  <option value="10"></option>
  <option value="20"></option>
  <option value="30"></option>
</datalist>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist#range...