Tagify项目中只读下拉框的可聚焦与编辑问题解析

问题现象

在Tagify的select/dropdown模式下，当组件被设置为只读(readonly)状态时，用户仍然可以通过键盘Tab键聚焦到已存在的标签上，并且能够进行字符删除或内容修改操作。这种交互行为与开发者对"只读"属性的常规预期存在明显偏差。

技术背景

Tagify是一个功能强大的标签输入库，其select/dropdown模式实现了类似选择框的交互体验。在底层实现上，每个标签实际上是由可编辑的SPAN元素构成，这种设计在常规编辑状态下提供了良好的用户体验，但在只读模式下却产生了意外的可编辑性。

问题根源

通过DOM分析可以发现两个关键设计缺陷：

1. 只读状态下内部SPAN元素仍保留contenteditable属性
2. 聚焦控制未做限制，缺少tabindex="-1"这样的无障碍访问控制属性

这种实现方式违反了WAI-ARIA的只读控件规范，即只读元素不应允许用户修改内容，但可以接收焦点用于辅助技术访问。

解决方案建议

从技术实现角度，建议采用以下任一方案：

1. 属性修正方案：

// 设置只读时同步移除可编辑属性
if(readonly){
    spanElement.removeAttribute('contenteditable');
    spanElement.setAttribute('tabindex', '-1');
}

2. CSS辅助方案：

.tagify[readonly] .tagify__tag > div{
    user-select: none;
    pointer-events: none;
}

3. 事件阻断方案：

// 在只读状态下拦截所有编辑相关事件
if(settings.readonly){
    tagify.on('edit:start', e => e.preventDefault());
}

最佳实践

对于表单控件的只读实现，建议开发者注意：

1. 视觉状态与交互状态必须保持一致
2. 键盘导航场景下的焦点控制需要特殊处理
3. 移动端和桌面端的交互差异需要统一测试
4. 辅助技术(屏幕阅读器)的兼容性验证

总结

表单控件的状态管理是前端开发中的常见挑战，特别是对于Tagify这类复合型组件。完善的只读实现不仅需要关注视觉呈现，更需要确保交互层面的一致性和安全性。开发者在使用此类库时，应当对边界条件进行充分测试，确保符合业务场景下的交互预期。