[whatwg] Re: Another alternative to select editable

Jim Ley wrote:

>>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.
>
>
> So you'd throw away the child elements in a WF2 UA?

Yes, throw away everything but <option>'s, <optgroup>'s --- any legal children 
of a <select>. It would ignore scripts, images, objects --- none of those would 
get into the DOM of a WF2 UA, because they aren't semantically children of 
<combo>'s. You could write:

<combo>
<option>1</option>
<option>2</option>
</combo>

if (in the distant future) you didn't care about backwards compatibility.

> That's slightly different behaviour, but it doesn't obviate the
> inherent problem that most people won't be actually using just the
> text entry system, they'll start using the mouse - watch a few folk.

That's if the rest of the entry doesn't also appear in the text field. In the
combos I write (I've gone through several iterations :) ), it does. Thus, you
can just tab out of it after the first few letters.

>>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 use knows the client is called beetle juice, don't give them
> the chance to pick up their mouse, get them to type in "beetle j" and
> hit search

That's what it does. Except they don't have to hit search, they just hit tab to
move to the next field, or enter to submit a search (depending on where it's used).

> - you can optimise this search in the client if you want
> (but the excessive download would often prevent this being sensible)

Yep, it runs on an intranet, so the download time is workable. There's ways of
optimising the speed which I haven't gotten around to --- for example, sending
the list in a separate javascript file that can be cached (a bit like the
proposed 'data' attribute of a select) or kept in a separate window on the
client for any future entries.

> Er, they're dead tree, and not with my right now :-)
>
> http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html
> discusses a related thing (although doesn't seem to be as adamant)

<off-topic> Interesting. It praises mac menus, which I've always disliked
because if we ever get 50 inch screens, it will be one pain in the butt to move
the mouse all the way up to the top of the screen all the time. (I'm
exaggerating the problem, but you get the idea.)</off-topic>

Otherwise I agree with most everything (in both links). Indeed, the second link
is an example of where the WHATWG can help improve things sooner rather than later.

Received on Tuesday, 29 June 2004 06:49:47 UTC