This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 12271 as part of operation LATER convergence. Originally filed: 2011-03-09 14:43:00 +0000 Original reporter: Ben Bucksch <ben.bucksch@beonex.com> ================================================================================ #0 Ben Bucksch 2011-03-09 14:43:27 +0000 -------------------------------------------------------------------------------- 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 ================================================================================ #1 Jonas Sicking 2011-03-22 02:58:21 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #2 Ben Bucksch 2011-03-22 12:44:17 +0000 -------------------------------------------------------------------------------- > 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. ================================================================================ #3 Jonas Sicking 2011-03-22 20:55:30 +0000 -------------------------------------------------------------------------------- > 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. ================================================================================ #4 Ben Bucksch 2011-03-22 21:24:08 +0000 -------------------------------------------------------------------------------- > <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. ================================================================================ #5 Ben Bucksch 2011-03-22 21:45:50 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #6 Ian 'Hixie' Hickson 2011-05-08 00:04:52 +0000 -------------------------------------------------------------------------------- (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. ================================================================================ #7 Ian 'Hixie' Hickson 2011-05-08 00:26:30 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #8 Ben Bucksch 2011-05-08 06:16:46 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #9 Ian 'Hixie' Hickson 2011-05-10 03:44:14 +0000 -------------------------------------------------------------------------------- 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. ================================================================================ #10 Ben Bucksch 2011-05-10 09:28:00 +0000 -------------------------------------------------------------------------------- > 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. ================================================================================