|Summary:||Master bug of datalist element and list attribute implementation|
|Product:||WebKit||Reporter:||Kent Tamura <tkent>|
|Severity:||Normal||CC:||adele, bronislav.klucka, changseok, cmarcelo, darin, d, dwim79, hyatt, info, iserg9, jonlee, mathias, mike, mjs, peter, p.jacquemart, rik, robertc, RobS.webkit6, rodger.combs, syoichi, teun, t.tom, webkit-bug-importer, webmaster|
|Version:||528+ (Nightly build)|
|Bug Depends on:||72006, 98934, 26915, 27756, 27794, 27800, 52214, 81196, 82871, 82874, 83117, 83742, 84343, 84344, 84346, 84351, 84353, 84356, 84359, 86821|
|Bug Blocks:||19264, 40829, 76198|
Description Kent Tamura 2009-07-14 01:50:23 PDT
I'll make a patch to support for `list' attribute. The UI will be like http://docs.google.com/View?id=dch3zh37_0cf8kc8c4
Comment 1 Kent Tamura 2009-07-27 21:23:50 PDT
Created attachment 33600 [details] Screenshot produced by actual code I have almost completed the code. Because the patch is large, I'll split it into some bugs.
Comment 2 Anthony Ricaud 2009-07-29 05:18:08 PDT
It doesn't look very native. A NSComboBox on MacOS feels nicer : http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/nscombobox_Class/Reference/Reference.html
Comment 3 Kent Tamura 2009-07-29 17:12:00 PDT
(In reply to comment #2) > It doesn't look very native. A NSComboBox on MacOS feels nicer : > http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/nscombobox_Class/Reference/Reference.html Do you think NSComboBox is nicer for <input type=search> or <input type=number> ?
Comment 4 Kent Tamura 2009-07-30 03:04:19 PDT
Created attachment 33765 [details] Reference patch This is a patch without ChangeLog and tests, for reference. I'll submit a complete one after all dependent patches are landed.
Comment 5 Peter Kasting 2009-08-04 15:59:35 PDT
dhyatt was working on <datalist> support, he should be CCed on all bugs about it
Comment 6 Kent Tamura 2009-08-18 17:14:54 PDT
Does anyone have an idea of better UI for list attribute support? If not, I'll update the patches and request to review them.
Comment 7 Aryeh Gregor 2010-01-21 16:52:44 PST
FWIW, Opera displays this the same as autocomplete suggestions. In other words, there's a dropdown that automatically appears when the user focuses the field and starts typing, and he can use the arrow keys or mouse to select an item from it. This is nice if you're trying to use <datalist> to implement search suggestions -- a combobox UI would be unusable for that use-case. Related WHATWG thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024794.html
Comment 8 Kent Tamura 2010-01-21 16:58:38 PST
(In reply to comment #7) I don't think the UI of Opera is the best. It's hard for users to know that a field has choices provided by the page author.
Comment 9 Aryeh Gregor 2010-01-21 17:02:51 PST
That's what's wanted for search suggestions -- they should look like browser suggestions. However, it's not wanted for comboboxes. It's not clear to me which way is "right". I've suggested to the WHATWG that perhaps a separate JS-only API should be specced for search suggestions, leaving <datalist> more clearly for comboboxes, but I expect it will be a while before I get a response on that.
Comment 10 Aryeh Gregor 2010-01-22 13:26:07 PST
Maciej suggested that for type="text", it should use a native combobox widget, while for type="search" it should look like search suggestions: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024799.html Does that make sense to you?
Comment 11 Kent Tamura 2010-01-24 23:18:19 PST
Hmm, the idea of type-specific appearance makes sense. So, we'll make the followings for <datalist> and list attribute? No special UI (text field) ==> Native combo-box Type=search ==> like search-suggestions Type=range ==> Markers Type=color ==> In the color chooser dialog? Type=number ==> Additional menu button (my original proposal) date/time types ==> ditto
Comment 12 Rodger Combs 2011-05-07 19:56:26 PDT
Agreed. Reference Safari's Google Search box for type=search. (In reply to comment #11) > Hmm, the idea of type-specific appearance makes sense. > > So, we'll make the followings for <datalist> and list attribute? > > No special UI (text field) ==> Native combo-box > Type=search ==> like search-suggestions > Type=range ==> Markers > Type=color ==> In the color chooser dialog? > Type=number ==> Additional menu button (my original proposal) > date/time types ==> ditto
Comment 13 Dongwoo Joshua Im 2011-09-21 23:45:03 PDT
Is this patch still going on? It looks almost done, but why it stops here?
Comment 14 Jon Lee 2011-09-23 13:36:21 PDT
Comment 15 Bronislav Klucka 2011-09-23 15:07:19 PDT
(In reply to comment #14) > <rdar://problem/10069956> Hi, I'm trying to stay informed... what does such element/URN/scheme means? How can I look at such content?
Comment 16 Darin Adler 2011-09-23 15:14:40 PDT
Those URLs are for Apple’s internal bug tracking system, Radar. For the most part, they are not useful to anyone who does not work for Apple except to communicate with people who do.
Comment 17 Tobias Tom 2013-10-17 06:19:30 PDT
I assume this issue is still blocked by some stuff in radar?
Comment 18 Darin Adler 2013-10-17 10:57:27 PDT
(In reply to comment #17) > I assume this issue is still blocked by some stuff in radar? I don’t think so. Not even sure what that question means.
Comment 19 Teun 2014-03-05 08:56:39 PST
Please make this very useful feature happen.
Comment 20 Domenic Denicola 2016-10-28 09:30:46 PDT
The spec has been updated with some concrete suggestions on display and string matching that might be helpful for those implementing this: https://html.spec.whatwg.org/multipage/forms.html#attr-input-list