[BUG] Using `list` autocomplete

[YonatanKra]

Hi, When using the form fields (mainly text field) and adding the list attribute, it has no effect. This happens because the data list is outside the shadow while the input element is inside the shadow. Here's an example that shows the issue: https://codepen.io/yonatankra/pen/OJQNXpb?editors=1111 In this example, there's a datalist outside the shadow - and the list attribute has no effect. Clicking the button appends the same dataList into the shadow DOM and you can see the autocomplete shows. Is there different way to make the list attribute work?

[au5ton]

This is still very much an issue that affects downstream components.

[chrisdholt]

@radium-v any ideas or thoughts here?

[au5ton]

The key issue is that <datalist> and the <input> need to be in the same document. Bringing the <input> into the parent document isn't ideal and defeats the point of encapsulation. I suppose it could be possible to copy the <datalist> from the parent DOM into the shadow DOM whenever the "list" attribute is specified, changed, or whenever a mutation happens to the source <datalist> itself (using MutationObserver).

In the example below, <fast-text-field> could be responsible for maintaining its own copy of <datalist id="ice-cream-flavors"> inside its shadow DOM, that it is then responsible for keeping its copy in sync with the original <datalist>

<fast-text-field list="ice-cream-flavors"></fast-text-field>
<datalist id="ice-cream-flavors">
    <option value="Chocolate">
    <option value="Coconut">
    <option value="Mint">
    <option value="Strawberry">
    <option value="Vanilla">
</datalist>

[radium-v]

This is also an issue with other web component libraries, such as PolymerElements/paper-input#595. @au5ton is correct that the issue lies with the platform and how it handles mapping ID'd elements between the light and shadow DOM.

I also vaguely remember this being a common problem with accessibility features which rely on ID mapping, like aria-labeledby, aria-describedby, aria-activedescendant, etc. but I could be mistaken.

One thing I tried locally was adding a slotted datalist, but even that doesn't get picked up by the text-field in any browser. We'd still have to resort to either copying an existing <datalist> into the shadow dom, or building a mechanism to allow for an array of options to be used to generate an encapsulated list.

An alternative for today may be to use the Combobox component, as that's functionally equivalent to an <input> with a <datalist>:

<fast-combobox autocomplete="list">
    <fast-option>Chocolate</fast-option>
    <fast-option>Coconut</fast-option>
    <fast-option>Mint</fast-option>
    <fast-option>Strawberry</fast-option>
    <fast-option>Vanilla</fast-option>
</fast-combobox>

This may work best when you only have one element that needs the list; if you have multiple inputs that all pull from the same list, this would lead to a lot of duplication (but then again, so would copying the original list into each element's shadow dom).

I feel it's worth noting that the native experience for datalist-bound inputs is subpar at best, especially on Android.

Here's an updated pen which includes the original bug behavior, a combobox, and a native input: https://codepen.io/kreitlow/pen/wvOazaX?editors=1010

[au5ton]

I agree that the native experience for datalist-bound inputs has its pain points. Maybe its wishful thinking, but the datalist standard is pretty mature and I think the idea of a truly built-in/native combobox that every browser can use without JavaScript is something that the web sorely needs. Personally, I'm a <datalist> advocate and I've been working on improving the experience in Firefox.

That aside, the situation for this specific bug leads me to understand that there are 2 possible options for addressing this:

1. Implement some workaround for the <datalist> across different DOMs (such as some of the ones mentioned above)
2. Remove support for the list attribute and reconsider its use in the future, in the event that web standards evolve to address the situation

Any thoughts on which direction the Fast team may lean? @radium-v

[janechu]

Unfortunately @microsoft/fast-components has been deprecated for some time.