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 ' ' . form_select_options($element) . ' ';

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.