Topic on Talk:OOUI/Archive 2

OOUI offers nothing that specific, but it is perfectly feasible and the kind of custom approach I'm settling on - using separate inputs for values and labels - is parallelled in other UI frameworks.

For the original report and some context, see https://phabricator.wikimedia.org/T335240

If it is not a bug, the question would be how to best work around the default behaviour of comboboxes which lets you select an option and submit a value, but confusingly, without displaying the relevant label to users. (By 'label' I don't mean the html element that may be associated with an input).

The common approach for option elements is to have the value/data assigned to the attribute 'value' and the label to the content of the element, but in OOUI, the accepted values go to an input in which you can type new things. Of course, inputs don't support that sort of separation of values and labels. Frameworks tend to solve this by introducing some kind of interaction with additional hidden elements, but I haven't been able to find out if OOUI has ever addressed this situation.

Maybe there are best practices I'm not aware of, or someone else has already cracked it!

A search for potentially related solutions on Github and Phabricator wasn't very fruitful, so I went ahead and started work on an approach involving a combobox widget and a hidden input widget that's just there to contain / accept the selected value. That seems to work well enough though I need to spend more time on it in order to keep the inputs in sync.