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.

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

(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> ?

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.

dhyatt was working on <datalist> support, he should be CCed on all bugs about it

Does anyone have an idea of better UI for list attribute support? If not, I'll update the patches and request to review them.

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

(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.

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.

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?

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

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

Is this patch still going on? It looks almost done, but why it stops here?

<rdar://problem/10069956>

(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?

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.

I assume this issue is still blocked by some stuff in radar?

(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.

Please make this very useful feature happen.

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

*** Bug 188857 has been marked as a duplicate of this bug. ***

Related: I just reported bug 203116, "Native text substitutions interfere with HTML <datalist> options resulting in crash"

I would like to see bug 201768, comment 2 added to this list as well.

All dependent bugs are closed. Marking as "RESOLVED CONFIGURATION CHANGED". Thanks!