我正在就这个问题征求意见。这将是一个很难将某人标记为正确答案的问题，因为这主要是意见，但如果你有很多UI经验，请分享你的理由。
因此，我在web应用程序中使用了一个完全使用JavaScript的下拉列表（select标记）。它曾经使用ASP。NET在更改下拉菜单时回发，并且与不同的浏览器非常古怪/不一致，而且速度非常慢。当您单击下拉列表，然后单击下拉列表中的某个选项时，焦点会停留在该下拉列表上，但索引/选项会发生更改。太棒了！如果您单击下拉列表，向下箭头指向您的选项，然后点击[ENTER]键，它会获取您的值，并尝试像提交按钮那样提交表单，如果有不正确的地方，就会出错。太棒了！
当最终用户首先单击下拉列表，然后在不单击选项的情况下将鼠标指针移动到选项顶部（显然是另一个选项），然后点击[TAB]键时，应该有什么行为[ANSWER#1]是否应该选择该选项并用制表符标记到下一个字段，或者[ANSWER#2] 请不要将此与单击下拉列表，然后用箭头指向所需选项并点击[TAB]键混淆。这将在选项卡之前选择该选项（更改索引）。
你要求推理，所以我从那里开始。你希望用户能够实现自己的目标，在下拉列表中选择一个选项只是达到目的的一种手段，而不是实际目标。他们在更高层次上思考他们试图完成的工作，你不想用下拉菜单的机制来分散他们的注意力。因此（a）你不希望他们不得不停下来思考你的下拉列表，（b）你希望他们对它如何工作的最初假设是真实的，这样他们就不会以这样的方式操纵它，即他们认为自己做出了选择，而小部件认为他们没有。
有两个原则：一致性和最少惊讶原则。看看其他下降。特别是，看看其他类似于下拉菜单或提供相同启示的控件。看看其他在概念上提供类似选择的控件。查看您的页面、网站中的其他页面、目标用户可能访问的其他网站以及目标用户可能熟悉的桌面应用程序。当你找到一些例子时，按照他们的做法去做。
如果你发现了一堆例子，但它们彼此不一致，那么你就选择最不令人惊讶的例子。想想不一致的负面影响——这很令人惊讶，从用户相互警告的意义上来说，这很了不起——并尽一切努力将这些事情最小化。