9785 2010-05-21 09:26:28 +0000 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) 2014-09-19 18:35:22 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#the-datalist-element NE P3 enhancement Unsorted 1 contributor ian annevk ian jonas mike mounir Ms2ger public-html-admin public-html-wg-issue-tracking robin public-html-bugzilla oldest_to_newest 35788 0 contributor 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 37233 1 jonas 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. 38807 2 ian 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. 40297 3 mounir 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. 40319 4 mounir 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 40518 5 ian 2010-10-03 18:37:57 +0000 Thanks, I'll take a look and see if the implementation experience suggests spec changes are needed. 40973 6 ian 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). 82062 7 mike 2013-01-24 07:45:20 +0000 This bug was cloned to create HTML WG bug 19025. 94126 8 ian 2013-10-01 23:01:40 +0000 Anyone know how much usage moznofilter="" is getting? I'm not seeing any developer chatter about this feature at all in a Google search for it. 109309 9 Ms2ger 2014-07-26 10:17:03 +0000 I filed <https://bugzilla.mozilla.org/show_bug.cgi?id=1044407>. 109419 10 ian 2014-07-28 21:27:40 +0000 FWIW I examined our internal data and found zero organic uses of moznofilter. (Finding zero uses of anything is actually quite impressive.) 111097 11 ian 2014-09-05 19:49:13 +0000 Given the data above, I think the way to go here is for browsers to always filter unless there's only a small number of options, in which case not filtering probably makes sense. Maybe we should hard-code that number in the spec? But then again, maybe not? Hard to say. 111820 12 ian 2014-09-19 18:34:09 +0000 I did what I described in comment 11, and I'm calling it a day for this bug. If there ends up being a need for nofilter beyond that, please do file a new bug (or reopen this one). Thanks. 111821 13 contributor 2014-09-19 18:35:22 +0000 Checked in as WHATWG revision r8792. Check-in comment: Suggest that browsers filter the list='' suggestions if there's more than 4 to 7. https://html5.org/tools/web-apps-tracker?from=8791&to=8792