Snaterlicious added a comment. The pros and cons were discussed in older comments already... I am reluctant to retrigger the discussion.
It boils down to the question is whether there should be a "selector" or a "suggester". (While it makes sense for a "selector" to use "hard" auto-completion, a "suggester" should not use "hard" auto-completion as that implies only the suggested values being valid.) On the one hand, I would agree to what should be applied to the page input box, technically, is a "selector". However, since the results are aggregated in an external scope, there is no reliance on the results delivered being accurate. Furthermore, results are delivered with a delay and it cannot be relied on results being supplied at all while the nature of a "selector" is to only allow selecting form a supplied set of values. As I stated before, I think "soft" auto-completion might be nice to have but, eventually, there is not enough (if any at all) benefit justifying the effort. Bottom line: Our implementation is torn between the fact that the applied widget should be a "selector" but, due to the technical circumstances explained above, a "suggester" seems to be more applicable. I tend to leaving it at the current state as that resolves in less implications. (This is a practical suggestion.) And in the end, a user already waiting for the API request should be fine with having to hit the "down" arrow in order to apply the suggested value. TASK DETAIL https://phabricator.wikimedia.org/T68437 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Snaterlicious Cc: Snaterlicious, thiemowmde, Lydia_Pintscher, Tobi_WMDE_SW, Wikidata-bugs, aude _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
