W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > May 2011

[Bug 12271] <input list=""> needs an event triggered on selection of suggestion

From: <bugzilla@jessica.w3.org>
Date: Sun, 08 May 2011 06:16:47 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QIxIN-0006tS-AV@jessica.w3.org>

Ben Bucksch <ben.bucksch@beonex.com> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #8 from Ben Bucksch <ben.bucksch@beonex.com> 2011-05-08 06:16:46 UTC ---

> 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
* 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.

Configure bugmail: http://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 Sunday, 8 May 2011 06:16:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:09 UTC