Use HTML5 datalists for autocomplete

The last time I checked, datalist was supported only by the latest version of Opera, nothing else. Is that enough for us to pay attention yet? Is it on the roadmap for anyone else? Does the JS support exist to emulate it on the 99% of the market that doesn't recognize it yet?

I don't want us looking at any solution that doesn't have to do with moving this functionality out of Core and to a 3rd party solution. Also, the @autocomplete property has absolutely nothing to do with enabling autocomplete functionality, only if a UA should present users with autocomplete fields (like username / email).

What I was mentioning to Mike on Twitter was that jQuery UI being the primary approach was causing issues for us on mobile, especially with regards to performance, download sizes, and touch screen support. We are finding that native HTML5 is much faster and more mobile friendly than jQuery UI (especially when paired with jQuery mobile) which is why we want to leverage HTML5 support first and use jQuery UI (and other JavaScript "emulation" solutions) as the fallback. There is already a lot of overlap between what HTML5 does and what jQuery UI does, for instance:

• HTML5: input type="range", jQuery UI: Slider
• HTML5: progress element, jQuery UI: Progressbar
• HTML5: input list attribute and datalist element, jQuery UI: Autocomplete
• HTML5: Drag and drop, jQuery UI: Draggable and Droppable

The issue is of course that HTML5 support is absent or only partially implemented in many of the browsers in use which is why we need a fallback solution for any HTML5-specific elements we use to ensure we provide support for all browsers.

The approach we are looking into is the following:

1. Starting with native HTML5 (in this case the input list attribute and datalist element)
2. Detecting whether the HTML5 elements/attributes in question are supported.
3. Overriding with a fallback solution (in this case jQuery UI Autocomplete) where the necessary HTML5 support is absent

There are likely several ways to implement the support detection + fallback mechanism (doesn't have to be part of the core). The key is we're trying to avoid people with native HTML5 support having to endure the much slower and less mobile friendly JavaScript equivalents, since those people are increasing rapidly in number day by day (especially in the mobile space).

Everett, I'm not clear what you mean. Autocomplete functionality absolutely cannot move out of core; we use it in core in several places. Not rolling out own implementation yet again, sure, I completely agree with, but that doesn't seem to be what's suggested here.

pjackson: Is there a way that we could do what you suggest (HTML5 and fallback to JS), or would those libraries have to be updated to do that themselves first? Also, another issue with datalist is that, last I looked, it didn't support dynamic lookup so large datasets would be prohibitive to send to the browser. (Think taxonomy autocomplete on a vocabulary with 800 tags. Sending all 800 to the browser would not fly at all.)

@Crell

If we replace autocomplete.js with anything, it should be a tried and tested solution, such as jQuery UI. If the approach Paul suggests above makes it into jQuery UI, then that is great. There is no reason for us to continue to maintain the autocomplete.js functionality when jQuery UI has a far better solution (accessibility aside) than our own.

I guess my objection is that we really shouldn't be thinking about doing anything to autocomplete.js other than replacing it with jQuery UI, and then we can look at enhancing that solution.

For the feature detection of this proposal to work then #1252178: Add Modernizr to core will needto be resolved.

@Crell: One way it could be done is:

1. Add the native HTML code (input list + datalist)
2. Wrap a div around the affected elements and apply a class name for identification (e.g., <div class="html5-autocomplete"></div>)
3. Have a script that scans the page for the relevant classnames (e.g., "html5-*"). For each type (e.g., "html5-autocomplete"), use something like Modernizr to detect if the element is supported
4. If it is supported, leave it alone. If it is not, use new script element injection to dynamically add the relevant libraries (e.g., jQuery UI) then call .autocomplete() on the relevant input elements (specifying the source as needed). This is to ensure that the supporting libraries are only downloaded if needed (to avoid an unnecessary 200kb+ hit along with extensive JS execution, which will affect mobile performance).

Ideally the above would be done asynchronously (e.g., adding the loader script tag to the end of the body rather than in the head) to minimize performance impact. You'd want to do this in a separate loader rather than through jQuery UI (unless jQuery UI implements a lightweight loader) as you don't want the 200kb+ hit and JS execution for browsers that have the necessary HTML5 support.

As for your second question, the "A dynamic combo box" section of An HTML5-style "Google Suggest" blog post on Dev.Opera seems to describe a good way to deal with dynamic lookup for large data sets. Ultimately you would need a solution involving a combination of JavaScript and server-side to pull off the dynamic lookup.

Yes, I've seen that article. As it notes at the top, the built-in dynamic update mechanism was removed from the spec so we'd have to reimplement it ourselves. We can do that, as long as it's performant. (Or ideally we make someone else do it and we just borrow it, like Everett correctly notes.)

I have no strong input here, other than agreeing with writing as little code of our own as possible and saying that you should treat callbacks to the server as something that should get easier in Drupal 8. We're working on it. :-) I don't know that it will be vastly faster, but there are people working on that, too.

Shouldn't be surprising that I agree with #4 and #9.

I would very much like to avoid the jQuery UI dependency for that. tagged.

If you use datalist don't you have to list every possible choice out in the code? I don't think this is viable solution for most sites. Imagine user and node reference widgets with every user and node listed in a datalist in the HTML output.

I don't see compelling arguments not to just switch to using jQuery UI autocomplete and maybe tabling this until the dynamic handling is improved.

nope, that wouldn't be discussed otherwise, nothing stops you from adding/removing <option> elements from your datalist.

Compelling argument is jQuery+UI autocomplete = 52kb of JS, not counting images/css required by jquery ui. This is not mobile friendly.

(edit) actually, it's less, but still around 45k.

This one is tricky, but I think we should attempt to figure it out. Whatever we use needs to be tested thoroughly, and the lack of browser implementations make that difficult right now. However, 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. What do you guys think?

Also, In an effort to get a better picture of issues remaining in the HTML5 Initiative, I'm going through the existing issues and prioritizing them. I'm bumping the priority of this one to major as it needs to be resolved soon for Drupal 8 as part of the HTML5 Initiative.

Thoughts on #14, in no special order:

- At first blush it seems very sensible; especially the no-Javascript part.

- This would be using datalist as a cheap "select-or-other" widget, not as a better auto-complete. I'd say that those are two separate issues, and therefore should be considered separately. Vis, having a select-or-other widget in core makes sense, and could be implemented that way, but we should also continue to explore using datalist as a better autocomplete as well. One or the other should fork to a separate issue.

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

So, I think #14 should split off to a separate issue for "select-or-other in core", and we can deal with the theming question there. Then we can continue to ponder autocomplete here.

Thinking a bit more about it, I think the way input text is matched to options in the datalist won't work. From what I could see it matches from the start of the word and is case sensitive. That means it's pretty much a no-go as far as autocomplete is concerned.

Why is that a no-go? If that's how the widget works, that's how the widget works. For auto-complete purposes, datalist doesn't do callback-to-server, so we'd have to implement that ourselves anyway and use it to populate the datalist. And we can certainly make our own callback case-insensitive.

the native widget is the issue, not the callback or the data.

Ok, a separate issue works for me. In that case, I'm changing this back to normal. While it would be great to resolve this autocomplete issue, it's not a critical MUST have IMO. The new issue is here #1593964: Allow FAPI usage of the datalist element.

Can't work for core autocomplete, see #16, and #19 is something we can do about it.

There's a good chunk of useful discussion and info here, so I think it's more appropriate to postpone this issue for now.

We can re-evaluate this after #1593964: Allow FAPI usage of the datalist element, and generally upon HTML5 spec improvements. Speaking of, the last evaluation happened 6 months ago here, which apparently can mean everything and the world in terms of the HTML5 spec and native browser implementations (as well as their behavior). ;)

Looks like support has greatly improved, but it's not universal yet:

http://www.iwanttouse.com/#datalist
http://caniuse.com/#search=datalist

HTML5 datalist never got significantly better.

I spent a lot of time with our autocomplete and native widgets don't have the necessary features for us. Hasn't changed in 10 years, it's time to lay this one to rest.