- From: <bugzilla@jessica.w3.org>
- Date: Tue, 25 Sep 2012 21:55:23 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19025
Summary: Add a "filter" attribute. If set, the user agent will
filter the datalist. If not, filter won't be filtered
automatically (unless you do some sort of filtering by
javascript or/and server-side)
Product: HTML WG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#the
-datalist-element
OS/Version: other
Status: NEW
Keywords: NE
Severity: normal
Priority: P3
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, annevk@annevk.nl,
jonas@sicking.cc, mounir.lamouri@gmail.com
This was was cloned from bug 9785 as part of operation LATER convergence.
Originally filed: 2010-05-21 09:26:00 +0000
================================================================================
#0 contributor@whatwg.org 2010-05-21 09:26:28 +0000
--------------------------------------------------------------------------------
Section:
http://www.whatwg.org/specs/web-apps/current-work/#the-datalist-element
Comment:
Add a "filter" attribute. If set, the user agent will filter the datalist. If
not, filter won't be filtered automatically (unless you do some sort of
filtering by javascript or/and server-side)
Posted from: 212.170.172.199
================================================================================
#1 Jonas Sicking 2010-08-04 18:36:59 +0000
--------------------------------------------------------------------------------
We ran into this issue too when discussing the firefox implementation of
datalist.
Two usage scenarios we could see for <datalist> are:
1.
A static set of completions which the user will usually choose between. For
example:
<input list=managers>
<datalist id=managers>
<option>Sven</option>
<option>Agneta</option>
<option>Björn</option>
<option>Håkan</option>
<option>Lisa</option>
<option>Anne-Frid</option>
<option>Benny</option>
</datalist>
2.
A dyanmically populated list based on more complex conditions. Consider for
example the google autosuggest feature.
<script>
function handleInput(value) {
var xhr = new XMLHttpRequest();
xhr.open("GET", "/suggestions.cgi?" + value);
xhr.send();
xhr.onload = function() {
document.getElementById("suggestions").innerHTML = xhr.responseText;
}
}
</script>
<input list=suggestions oninput="handleInput(this.value);">
<datalist id=suggestions></datalist>
In use case 1 it makes sense for the UA to only display results that contain
(or even starts with) the string that the user has typed so far. In use case 2
it makes sense to display *all* the results that the server cgi script thought
were relevant. For example if I type "200 sek" in google, the first result it
shows is "200 Swedish kronor = 27.9998 US dollars".
I suspect that letting the UA apply filtering is a reasonable default. However
it would be very good to be able to set a boolean attribute on either the
<input> or the <datalist> stating that filtering should not happen.
================================================================================
#2 Ian 'Hixie' Hickson 2010-09-10 09:16:36 +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:
Currently the spec doesn't say if there should be filtering or not — it just
says that these are the suggested values and leaves the UI to the UA.
The idea here is to provide a combo box, not to provide a "Google suggest"-like
interface. The latter would probably be better handled by a pure JS solution
with callbacks.
I would recommend that browser vendors play with offering different attributes
(using the vendor-extension syntax!) to experiment with what the best way to
extend this feature would be, and report back. We can then update the feature
appropriately.
================================================================================
#3 Mounir Lamouri 2010-09-30 20:50:50 +0000
--------------------------------------------------------------------------------
Gecko has this kind feature implemented (will be in Gecko 2.0/Firefox 4).
Reopening to keep that in mind.
================================================================================
#4 Mounir Lamouri 2010-09-30 22:12:27 +0000
--------------------------------------------------------------------------------
This thread describes the current Gecko behavior and why we do that:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-September/028741.html
================================================================================
#5 Ian 'Hixie' Hickson 2010-10-03 18:37:57 +0000
--------------------------------------------------------------------------------
Thanks, I'll take a look and see if the implementation experience suggests spec
changes are needed.
================================================================================
#6 Ian 'Hixie' Hickson 2010-10-12 06:26:13 +0000
--------------------------------------------------------------------------------
The current situation (a mozNoFilter attribute) seems reasonable for
experimentation. Let's revisit this a few months after this has been shipped
widely, and see how people are using it. I think this is definitely an area
where we'll need to add new features to the platform, but I'm not sure it makes
sense to do it straight away we don't want to go too far down a rabbit hole
without the reality check of author usage, the further we go the harder it will
be to climb back out, as it were (e.g. we'll end up with features that are
hardly used but used enough to require implementation everywhere, which is a
high burden on the platform).
================================================================================
--
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:26 UTC