[whatwg] Re: Another alternative to select editable

[voracity]

Jim Ley wrote:

> Oh sorry, I misread your example, I think this is equivalent to the
> fieldset proposal, just using a new element, rather than an attribute
> on fieldset

I don't think your entire proposal made it to the list (at least I can't see 
it). What I saw was the following:
<fieldset> Enter <input type="text"> or Select <select/>
</fieldset>

Which is similar. However it either doesn't do anything that can't be done 
today, or more likely it changes the meaning of <fieldset> so that WF2 browsers 
have to parse the content to be equal to a <select editable>. (i.e. I'm not 
entirely sure what the DOM would look like.)

With <combo> (or something similar), the DOM would look exactly like it does for 
a single select and the syntax is cleanly related to the DOM.

 > I don't see anything wrong with it either, Last I read
> Ian was "looking at it", but heard nothing since.

here's hoping we hear something soon.

> If you can "search" reliably to it, then do that

Hmmm, I see. I think we have different ideas about how something like <select 
editable> would work. It _ought_ to search the list for a match. In particular, 
the list would be sorted alphabetically, and it would skip to the first option 
with the letters you type. If you type something not on the list, the search 
would obviously stop and allow you to type in the new item.

 > you just need a text
> box and a search mechanism, perhaps divide it into categories, or
> similar, but navigating a drop down list with 1000's of elements in is
> generally not very usable (keyboard users often can use it reasonably
> efficiently, but we shouldn't sacrifice the work in.)

I can understand how it wouldn't be usable in many cases. However, in this 
(probably common) case, the list of clients is categorisable only by the letters 
that make up the client's name (all other categorisations would be less 
efficient). I suppose you could divide client's by letter, so that users have to 
choose  'B', then 'E', then 'E' for the client called 'beetle juice', but that 
just isn't practical --- and it's why we have keyboards :)

If the user isn't expected to know what letters the desired option starts with, 
then I agree that it is not very efficient (though this could be fixed in some 
cases by searching for substrings --- or, for programmers, regular expression 
matches ;) ).

 > If you look at
> most UI guides they don't suggest using combo boxes for more than you
> have to scroll to get to, scrolling is too difficult a function AIUI.

I agree that scrolling that kind of a list is very painful. I would actually 
prefer if the combo box restricted the list to just those options that match 
what the user entered (essentially like an autocomplete field). Perhaps a better 
name would be <lookup>?

Also, could you point me to some useful UI guides that discuss 
combos/autocompletes/etc. (I'm not a UI guru, I rely on intuition). I'd be 
interested to see how others tackle similar problems.