Bug 27247 - Master bug of datalist element and list attribute implementation
: Master bug of datalist element and list attribute implementation
Status: NEW
: WebKit
Forms
: 528+ (Nightly build)
: All All
: P3 Normal
Assigned To:
: http://www.whatwg.org/specs/web-apps/...
: InRadar
: 26915 27756 27794 27800 52214 72006 81196 82871 82874 83117 83742 84343 84344 84346 84351 84353 84356 84359 86821 98934
: 19264 40829 76198
  Show dependency treegraph
 
Reported: 2009-07-14 01:50 PST by
Modified: 2014-03-05 18:33 PST (History)


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


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-07-14 01:50:23 PST
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 From 2009-07-27 21:23:50 PST -------
Created an attachment (id=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 From 2009-07-29 05:18:08 PST -------
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 From 2009-07-29 17:12:00 PST -------
(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 From 2009-07-30 03:04:19 PST -------
Created an attachment (id=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 From 2009-08-04 15:59:35 PST -------
dhyatt was working on <datalist> support, he should be CCed on all bugs about it
------- Comment #6 From 2009-08-18 17:14:54 PST -------
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 From 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 From 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 From 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 From 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 From 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 From 2011-05-07 19:56:26 PST -------
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 From 2011-09-21 23:45:03 PST -------
Is this patch still going on? It looks almost done, but why it stops here?
------- Comment #14 From 2011-09-23 13:36:21 PST -------
<rdar://problem/10069956>
------- Comment #15 From 2011-09-23 15:07:19 PST -------
(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 From 2011-09-23 15:14:40 PST -------
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 From 2013-10-17 06:19:30 PST -------
I assume this issue is still blocked by some stuff in radar?
------- Comment #18 From 2013-10-17 10:57:27 PST -------
(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 From 2014-03-05 08:56:39 PST -------
Please make this very useful feature happen.