Input components do not expose autocomplete property

[mollykreis]

🐛 Bug Report

Nimble input fields (text field, number field, maybe others?) do not expose an autocomplete field to modify the autocomplete behavior of the browser.

This property exists on the native input: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete

💻 Repro or Code Sample

🤔 Expected Behavior

A developer should be able to configure the autocomplete property that is used on an input field.

😯 Current Behavior

A developer can't configure the autocomplete property on input fields. As a result, the browser's default autocomplete behavior always occurs, which isn't necessarily the desired behavior. For example, in an app, it may always have autocomplete on a field that should not have autocomplete, and there isn't a way to control what values a given input provides as autocomplete options.

💁 Possible Solution

Expose an autocomplete property on nimble inputs. I haven't done a thorough evaluation of what controls this should include, but I expect it to include the nimble-text-field, nimble-number-field, nimble-text-area, and possibly more.

The nimble-combobox already has an autocomplete property that has an entirely different meaning & possible values than this new property, so we'll have to decide if we're happy with autocomplete meaning different things for different components.

🦆 Workaround

In a desktop blazor hybrid app where the webview native autocomplete isn't expected on a desktop experience, one can leverage IsGeneralAutofillEnabled and IsPasswordAutosaveEnabled

🔦 Context

🌍 Your Environment

I ran into this in a Blazor app, but I would expect it to impact other frameworks as well.

[mollykreis]

I talked with @rajsite, and the proposal for addressing this issue is:

• On the nimble-text-field, nimble-number-field, and nimble-text-area, add a string? property called autocomplete (matching the native property). That property value will be set on the underlying input in the template.
• We will not do any complex typing of the value (i.e. stick with string?) because exactly matching the type of the native property is low ROI.
• We can evaluate adding a similar property in the future to the nimble-select (forwarded to the search input for a filterable select) and to the nimble-combobox (which already has an autocomplete property with a different meaning), but neither of those components need to be considered in the first pass of adding this property.