- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Sep 2012 21:55:11 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19024
Summary: <input list=""> needs an event triggered on selection
of suggestion
Product: HTML WG
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: HTML5 spec
AssignedTo: dave.null@w3.org
ReportedBy: contributor@whatwg.org
QAContact: public-html-bugzilla@w3.org
CC: ian@hixie.ch, mike@w3.org,
public-html-wg-issue-tracking@w3.org,
public-html@w3.org, jonas@sicking.cc
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.
================================================================================
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 25 September 2012 21:55:13 UTC