[Bug 20400] New: datalist Spec Oversight Limits Usefulness

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20400

            Bug ID: 20400
           Summary: datalist Spec Oversight Limits Usefulness
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: w3@nicholassloan.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

Back in September, I identified some issues with the datalist element and
related portions of the spec that led to questionably usefulness. Here is the
post to the mailing list:
http://lists.w3.org/Archives/Public/public-html-comments/2012Sep/0006.html

The biggest barrier to usefulness of this feature is that it doesn't define a
way to show a label to the user, rather than the value. Consider the following:

<datalist id="users">
<option value="1" label="Nick">
<option value="2" label="Hank">
<option value="3" label="Frank">
<option value="4" label="Nick">
</datalist>

<input type="text" list="users">

I can't guarantee that the names of my users will be unique, making name an
unsuitable field for the value of these options. So instead I choose to use an
id integer from the database row... a very common practice on the web. The
problem is the user experience: the id isn't something that users know or care
about, so making it the criteria that users search on, and the label displayed
to them upon selection is not effective.

To solve the searching aspect of this issue, user-agents should be instructed
to also search on the label field at minimum. Additionally, user-agents should
give expose an attribute or API that allows developers to tell the input
whether to search based on label or value. It may also be helpful to include
APIs for letting the developer define how searching works.

To solve the presentation issue in search results, only the label should be
shown if it is present. Otherwise, the value should be shown.

There may be a simple solution to the presentation of the input element's
value. Displaying a select element as a search box when a list attribute is
present might make a lot of sense. This already shows a label rather than a
value, and can scale up to support multiple selected items pretty naturally.
Think along the lines of how Chosen.js works
(http://harvesthq.github.com/chosen/). The datalist feature is clearly meant to
enable the same sort of interactions that Chosen.js does, so using Chosen as a
model for the feature seems reasonable.

There may be another option if you let developers display one value in an text
input element and submit another, but that seems potentially very messy.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Saturday, 15 December 2012 01:16:16 UTC