Bug 27247 - Master bug of datalist element and list attribute implementation
: Master bug of datalist element and list attribute implementation
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Forms
: 528+ (Nightly build)
: All All
: P3 Normal
Assigned To: Nobody
http://www.whatwg.org/specs/web-apps/...
: InRadar
Depends on: 72006 98934 26915 27756 27794 27800 52214 81196 82871 82874 83117 83742 84343 84344 84346 84351 84353 84356 84359 86821
Blocks: HTML5Forms html5test 76198
  Show dependency treegraph
 
Reported: 2009-07-14 01:50 PDT by Kent Tamura
Modified: 2014-10-31 11:09 PDT (History)
24 users (show)

See Also:


Attachments
Screenshot produced by actual code (11.77 KB, image/png)
2009-07-27 21:23 PDT, Kent Tamura
no flags Details
Reference patch (25.53 KB, patch)
2009-07-30 03:04 PDT, Kent Tamura
tkent: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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
<rdar://problem/10069956>
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.