[whatwg] Quick thought on the Combo Box problem...

Matthew Raymond wrote:
>> A point about the DOM: I'd like the currently selected node to be 
>> exposed. Thus if a person has chosen (or typed) 'Choice 2', you could 
>> use 'combo1.selectedNode' to get the chosen element (i.e. <item 
>> value="Choice 2"/>). If the user has typed something new (or hasn't 
>> type anything at all), then 'combo1.selectedNode' would be null.
> 
> 
>    I don't understand what you want.  The selected value will always be
> in the |value| attribute of the input control. If the user changes that 
> value, it will still be in the |value| attribute. Why would you need to 
> know the selected <item>? (I'm not saying there might not be a scenario 
> where you'd need to know the <item>, but I don't see that being 
> necessary in a situation where you aren't simply using <select>.)

a) So I can determine in a script whether something new (not on the list) was 
entered and b) so I can add my own attributes to each <item> that I can then use 
to do other things with.

I can do that without .selectedNode, but it would be more painful (and probably 
slow for big lists). And, ultimately, it would always be a hack that implements 
something exactly like .selectedNode.

> 
>    That give me an somewhat questionable idea:
> 
> <cl id="list1">
>   <item value="Choice 1" />
>   <item value="Choice 2" />
>   <item value="Choice 3" />
> </cl>
> 
> <label for="combo1">Drop-Down 1: </label>
> <input type="text" editable="false" name="dd1" list="list1" />
> 
>    It would do the same thing as a <select>.

If you substitute allownew="false" for editable="false", then that is something 
I would like to be able to do. (i.e. the person can type or select an entry, but 
if they type something not on the list, it isn't allowed). It's exactly like a 
select (in mozilla, at least), except the visual representation would mean the 
user would realise that they can also type to search for an option. Also, the 
user would get a visual indication of what they've typed so far.

However, I don't think there should be an attribute like 'allownew' or 
'editable', because it's too easily abused (i.e. people might use this instead 
of <select>). Having to script the behaviour would be disincentive enough.

I should be clear that I had originally modelled <combo> to be similar to the 
combo boxes in ms access. The current widget is more like an autocomplete 
widget. However, with a few scripting aids (such as .selectedNode), it will 
still be _easy_ to replicate (and go beyond) a combo. That practice is unlikely 
to be common on the web, which is why leaving it in scripting is acceptable.

Received on Wednesday, 30 June 2004 10:14:32 UTC