This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
4.10.7.2 Common input element attributes 4.10.7.2.3 The list attribute Current spec text: > When the user selects a suggestion, the input element's value must > be set to the selected suggestion's value, as if the user had written > that value himself. While this implements an autocomplete widget, and allows labels, the action should be configurable by the page, using an event handler, e.g. onListSelect. Just specifying that the value must be set/added to the textfield, as you currently do (quoted above), fails many important usecases: 1. Your own example of email address autocomplete, under section "The multiple attribute". Here, you conveniently let only the email address be added to the textfield, but that's neither user-friendly nor what current email clients like Thunderbird do. Instead, they add "Arthur Dosh <art@example.net>" instead of "art@example.net", but that would not work in your example with the labels. 2. While writing something akin to Firefox' awesomebar, I need something that triggers different actions based on what's selected: We either load the selected URL, or we start a search with the proposed search term (whereby the search term is the value), or we start a search with a given search engine (we have several search engines, and suggest providers, and the search needs to go to the engine that provided the suggestion). This can only be done with custom actions. I'm sure there are tons of other cases where the action must be something else other than just setting/adding the text to the textfield. As said, this could be solved with simply adding an event that's fired when the user selects an item from the list. The default handler could still be to set/add the value as text to the textfield. If the element does not have a multiple attribute specified or if the multiple attribute does not apply
Usecase 1: There is nothing that says that the displayed value should be "art@example.net". The UA could display "Arthur Dosh <art@example.net>" while making .value and the submitted value be "art@example.net". However in some instances, like an webmail app, you really do want the submitted value to be "Arthur Dosh <art@example.net>". For now the HTML5 spec doesn't satisfy that usecase very well I agree. The best you can do is simply use <input type=text list=foo>. But I'm not sure how adding an onListSelect helps here? Usecase 2: If you want to build something like the awesomebar then it's not as simple as adding onListSelect. We only actually navigate if the user clicks or press enter. If you for example press a key-combo which moves focus to elsewhere we don't navigate. One thing that would make a lot of sense to me would be to fire the "change" event when the user selects something from the @list dropdown. Even if focus isn't moved to elsewhere. The "change" event is usually fired when there is some sense of finality in what the user has entered, rather than simply being in the middle of actively editing the value. That seems to match fairly well with when a value is selected from the @list. Sure, the user could continue editing the value, but it seems somewhat likely that they don't. That's similar to when you remove focus from a field. You could certainly move focus back and edit then too.
> One thing that would make a lot of sense to me would be to fire the "change" > event when the user selects something from the @list dropdown. Even if focus > isn't moved to elsewhere. The "change" event is usually fired when there is > some sense of finality in what the user has entered, rather than simply being > in the middle of actively editing the value. First off, maybe there's a misunderstanding. When I say "selection" / "onListSelect", I mean that the user explicitly clicked on an entry with the mouse, or he pressed Enter, Return or Space with the keyboard. I do *not* mean that another list entry is highlighted after a mere mouse hover or keyboard cursor keys. > like an webmail app, you really do want the > submitted value to be "Arthur Dosh <art@example.net>". For now the HTML5 spec > doesn't satisfy that usecase very well I agree. Exactly. (And I just took that example, because the spec used that, but there are even clearer ones.) > But I'm not sure how adding an onListSelect helps here? If label = "Arthur Dosh", value = "art@example.net", the dropdown display would be fine (in this case). Opon selection, my code takes label + " <" + value + ">" and fills that into the textfield, possibly appending ", ", too. More generally, the value that I fill in may not have anything to do with what I show to the user in the dropdown and what I autocomplete to. Another usecase: for database frontends, I may want to show only the name of the person, but fill in the database ID. The user should never see the database ID, but the ID is what my app actually uses. The user should be able to type to autocomplete to the name. (I am not sure the input list or any other HTML5 widget covers this usecase well, but this proposal here would be a start.) [awesomebar] > If you for example press a key-combo which moves focus to elsewhere we > don't navigate. Maybe that's a misunderstanding, but I just meant that pressing keyboard Enter/Return/Space, as well as mouse clicks, should trigger onListSelect, and I start my action, e.g. loading the URL, starting a search (with various search engines), switching the tab etc., depending on which entry the user selected. The last thing - action changes depending on which entry the user selected (and the entry's properties) - is not possible currently and critically important.
> First off, maybe there's a misunderstanding. When I say "selection" / > "onListSelect", I mean that the user explicitly clicked on an entry with the > mouse, or he pressed Enter, Return or Space with the keyboard. I do *not* mean > that another list entry is highlighted after a mere mouse hover or keyboard > cursor keys. Yes, I assumed that. Not sure what indicated otherwise? > > But I'm not sure how adding an onListSelect helps here? > > If label = "Arthur Dosh", value = "art@example.net", the dropdown display would > be fine (in this case). Opon selection, my code takes label + " <" + value + > ">" and fills that into the textfield, possibly appending ", ", too. > > More generally, the value that I fill in may not have anything to do with what > I show to the user in the dropdown and what I autocomplete to. So just do <input type=text list=mylist multiple> <datalist> <option label="Arthur Dosh" value="Arthur Dosh <art@example.net>"> ... </datalist> > Another usecase: for database frontends, I may want to show only the name of > the person, but fill in the database ID. The user should never see the > database ID, but the ID is what my app actually uses. The user should be > able to type to autocomplete to the name. (I am not sure the input list or > any other HTML5 widget covers this usecase well, but this proposal here would > be a start.) This doesn't sound like a <input> element at all since I'm assuming you don't want the user to be able to type arbitrary values, but rather just select from a list. I.e. the user should only be able to select valid IDs, right? This sounds much more similar to a <select multiple>. Unfortunately the UI for those are pretty terrible right now. In part this UI is forced upon browsers since if they tried to change it web authors would likely throw a fit since existing pages would change so dramatically. Maybe we could add some attribute to <select> which would opt in to a better UI somehow.
> <option label="Arthur Dosh" value="Arthur Dosh <art@example.net>"> That results in a different entry display, a suboptimal one. Your responses are not accommodating the last and most important part: > I start my action, e.g. loading the URL, starting a search > (with various search engines), switching the tab etc., > depending on which entry the user selected. > > The last thing - action changes depending on which entry the user selected (and > the entry's properties) - is not possible currently and critically important. I have this problem very concretely and cannot use the widget (or any other HTML5 widget), due to this bug.
To expand on this a bit: I am trying to write an autocomplete widget which can display autocomplete suggestions from several sources. The source provides the entry and the action corresponding to the entry. Current sources we have are: - Bookmarks / history label = page title, value = URL Selecting it loads the page directly - Personal search history (previous search terms used by this user) label = search term Selecting it runs the search again, using the default search engine - Web search (Google) suggestions Selecting it runs the search, using the search engine that suggested the term. The engine may be e.g. Google, Yahoo, Wikipedia or Amazon, *and* we mix them together in the results, i.e. a Google and a Wikipedia result may appear in the same list. Of course, this is just my usecase, but you can easily imagine other usecases in other areas, which have the same problem.
(In reply to comment #1) > One thing that would make a lot of sense to me would be to fire the "change" > event when the user selects something from the @list dropdown. Even if focus > isn't moved to elsewhere. This is already allowed (indeed, required). Selecting a value in this manner is a "commit" action, which is required to fire a 'change' event.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: > 1. Your own example of email address autocomplete, under section "The multiple > attribute". Here, you conveniently let only the email address be added to the > textfield, but that's neither user-friendly nor what current email clients like > Thunderbird do. Instead, they add "Arthur Dosh <art@example.net>" instead of > "art@example.net", but that would not work in your example with the labels. If you want to submit more than e-mail addresses, then type=email isn't for you, so this doesn't seem like a big problem here. You can do this with type=text already. > 2. While writing something akin to Firefox' awesomebar, I need something that > triggers different actions based on what's selected That doesn't seem like an autocomplete widgets. If there's some state beyond the value, then how is the user supposed to type it in? The idea of autocomplete here is that the feature just allows the user to avoid having to type something in that they would normally be able to type anyway.
REOPEN > You can do this with type=text already. This bug is about <input type=text list=foo>, and no, I can't do that. > That doesn't seem like an autocomplete widgets. If there's some state beyond > the value, then how is the user supposed to type it in? The idea of > autocomplete here is that the feature just allows the user to avoid having to > type something in that they would normally be able to type anyway. This bug isn't about an "autocomplete" widget in the sense of autocomplete=on either. It's about the need of a widget where the user can select one of several given values by means of typing text (or optionally enter a new thing). This widget *does* use state other than the text, yes. I gave several examples: * enter names from address book (which has more info than just the email address, and that info must be carried on), and *display* the names, not the email addresses, and *use* the email addresses, not the names. * In a database application, selecting a foreign key, e. g. order -> customer ID. The user sees the customer name, *never* the customer ID, but the customer ID is written in the database. This is a classical use of a combobox, yet there is state required which should not be shown to the user, much less filled in as value. * Search field, with a default search action, but "enhanced" with search suggestions from other sources (described above). A combobox with a list of options, and the programmer being able to store an object with each option, and that object being accessible when the option is selected, is something that most good toolkits can do. Not being able to do that is facepalm and speaks of an inmature toolkit. This proposal is trivial, obvious, and solves very important use cases.
What you're describing is an entirely new widget. We don't have anything currently that lets you store state beyond what is actually there. We might want to add that it due course, but just adding an event for when you pick something from a list wouldn't be close to sufficient for a sane UI. I'm not aware of any real-world widget which is a simple text field with a simple autocompletion drop-down that does anything like what you describe. There are some widgets out there that do this kind of thing, e.g. the date format editor in Mac OS X's preferences (though it doesn't use autocomplete to get the effect, it just has a palette and uses drag-and-drop), but none that could just be implemented the way you describe. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: none yet Rationale: If we add such a widget we need a lot more research. We should do that once the current set of widgets have been properly implemented.
> What you're describing is an entirely new widget. What I describe would be possible with this widget, if you just add that one event. That's why I made this request. > just adding an event for when you pick > something from a list wouldn't be close to sufficient for a sane UI. Why? I have actually done that, I have implemented such a widget, and I have tried to implement it based on <input list="">, and what blocked me was this bug, this one event missing. Because of this bug, I had to implement the whole autocomplete dropdown by myself from scratch, including all key and mouse event handling, scrolling, focus, sizing. > I'm not aware of any real-world widget ... that does anything like what > you describe. I gave 3 real-world examples.
mass-moved component to LC1
This bug was cloned to create HTML WG bug 19024.
I'm thinking Web Components will probably end up being the solution here. The more I look at the use cases in comment 0 and comment 2, as well as the widget mentioned in comment 9, the more I think this is really asking for a custom presentation for what superficially looks like a textbox control. On the Web, the G+ circle picker UI ("+ Add names, circles, or email addresses") is a good example of what we're talking about here: a control with a drop-down menu listing labels, which when selected display in a fancy way and get submitted as machine-readable values rather than as the labels.
Sorry, I fail to understand why you keep talking about new widgets. The existing widget is what I need and works fine. All I need is an event that tells me that a certain user action happened. This is a trivial addition of a single event, but that addition allows for a much better and much more powerful use of the already existing widget.
None of the existing widgets come close to any of those use cases as far as I can tell. Which one do you think it is?
It's in the title and the first lines of the initial description: <input list=""> with <datalist>. With this, I had a fully functional autocomplete widget: a textfield with a dropdown, and when the user enters something, we are searching through the dropdown entires and the one that matches the user's entry is selected. The user can also select something with the mouse, and scroll. This whole UI with dropdown and searching and scrolling and keyboard arrow movements is already implemented by the browser, and is exactly what I need. However, I need a different *action* on selection, not insertion of the text. The only thing missing in the browser/spec was that there was no event fired which notified me of the important fact that the user selected an entry in the dropdown, and to stop the default action. There was no way to implement my own selection action, and this was a total blocker for me, and I had to abandon the widget and entirely reimplement it myself. The widget as-is was good for me, all the UI, input handling,etc.. All I wanted was to control what happens when the user selects an item. The simple addition of this event would allow me to do a lot more with this autocomplete widget.
Even if you get an event telling you that the user selected something (which you can already tell today, because the control's value would match one of the autocomplete values, so oninput is sufficient), it still wouldn't make the element's actual value be something different than the rendering, which is what that use case actually needs.
Punting pending Web Components.
This isn't asking for a new widget. It's just asking for a simple event, for the webapp to be notified when an important event happened, namely the user selected something. For me, it's a matter of course that this event needs to exist. In addition, it allows new important usecases which come out naturally from that.
No use case has been presented which would be satisfied by just adding such an event. If that's all this bug is about, then it is currently suffering from insufficient use cases to justify the feature request.
I've presented plenty use cases, in comment 8 and comment 5. And yes, all that would be possible with just this one event. Without this event, it is impossible to achieve what I wanted. I know, because I've concretely tried to implemenent it and was stuck. All that was missing was this one event. Eventually, I had to write my own widget entirely from scratch, including dropdown UI and more importantly keyboard handling. This I would like to be provided by the widget. The list contents and text field values I would like to determine myself. With this one event, I would be able to do that, I had the code ready to work and was just lacking this one event.
Could you link to an implementation of a widget such as the ones you describe in comment 8 or comment 5 where simply adding this event would make it work? You can pretend that the event is called "open", if you like.
The Bugzilla bug tracker for HTML is being shut down, so I am doing a final issue triage pass. As far as I can tell the input event satisfies this use case: https://jsbin.com/?html,console,output As such, I will close this as WORKSFORME. If we have misunderstood the issue, then please continue the discussion on https://github.com/whatwg/html/issues . If you do so, please include a direct answer to comment 22.