Combobox可以输入文字，为什么仍可能只接受列表中的值

一个输入框旁边带有候选列表，用户还能打字，就一定允许填写列表之外的内容吗？W3C的Combobox Pattern明确区分两件事：控件是否支持文字输入，以及它的值是否限于一组允许值。可编辑的combobox既可能接受任意值，也可能仍限制在离散集合中；后一种情况下，输入文字用于筛选弹出内容中的建议。[1]

APG把combobox描述为带有关联popup的输入控件。popup可以呈现允许值，也可以呈现建议值，这两种词的含义不能混写。允许值限定能取什么，建议值则帮助表达可能的选择。只看到一个弹出列表，还不足以知道它是在列出全部允许范围，还是在为自由输入提供参考。

select-only与editable回答的是输入方式。前者不支持文字输入，只能通过选择popup里的值设定结果；后者支持输入和编辑，但范围还要另看。因而，设计说明中的“可编辑”不应被自动扩写成“用户填写什么都可以”，更不能仅凭控件外观认定真实系统已经采用某一种模式。

自动完成又引入第三层关系。APG列出无自动完成的情形：控件可编辑，但弹出建议不随所输入的字符改变，例如始终呈现最近用过的若干值。这里没有根据输入生成新建议，不表示控件不能编辑；输入能力与建议如何产生依然分开。

在带手动选择的列表自动完成中，建议可以与已输入文字相对应，但用户输入的字符串会成为控件值，除非用户选择popup中的某项。自动选择则不同：首个建议会自动突出为选中项，控件失去焦点时，这个建议成为值，除非用户选了其他建议或修改了输入字符串。只写“显示候选”，会遗漏最终取值条件。

inline autocomplete在自动列表选择之外，再把尚未输入的补全部分显示在光标后面。这是呈现和选择行为的进一步组合，不是把每一个能打字的combobox都定义为自动补全。本文说明这些模式关系，没有执行输入、键盘或读屏测试，也没有把建议值当作某项真实业务数据。

对交互设计交接，可以分别问清三个对象：用户能否编辑文字，值是否限于允许集合，建议怎样参与最终取值。这是作者对模式的阅读分析，不提供实现代码或属性配置。它比一句“带下拉的输入框”更能说明双方讨论的行为，却仍需要实际实现证据来确认某个产品属于哪一种。

本篇采用APG的About This Pattern及Examples和邻接，首次发布日期未确认，后文键盘与ARIA实现细节不在本文采用范围。模式资料不是完整可访问性认证，也不保证任一浏览器或辅助技术的实际行为。准确留下取值条件，才不会让一个可编辑外观代替真正的交互定义。