[whatwg] Re: Another alternative to select editable
subs at voracity.org
Tue Jun 29 05:53:03 PDT 2004
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/>
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.
More information about the whatwg