:read-write仅匹配原生可编辑控件中实时可编辑的子集，不支持contenteditable元素，且对JS动态状态无响应；input需为可输入类型且未禁用、未遮挡，textarea同理，select兼容性差，div[contenteditable="true"]永远不匹配。
:read-write 不能可靠选择所有允许用户输入和编辑的字段——它只匹配原生可编辑表单控件（input、textarea、select）中“当前可写”的子集，完全不覆盖 contenteditable 元素，且对 JS 动态切换状态无响应。
哪些元素真正匹配 :read-write
浏览器按规范实时判定“是否具备内在文本编辑能力”，不是看有没有 readonly 属性，而是综合以下条件：
-
input必须是可输入类型（如text、email、number），且未设readonly属性、未设disabled、未被pointer-events: none或tabindex="-1"阻断交互 -
textarea同样要求无readonly、无disabled，且 DOM 中实际可聚焦 -
select在部分浏览器中匹配，但行为不一致（Chrome 支持，Safari ≤15.3 不支持） -
div[contenteditable="true"]❌ 永远不匹配 —— 这是标准行为，不是 bug
:read-write 和 input:not([readonly]) 的区别在哪
表面都“挑没只读属性的输入框”，但底层逻辑完全不同：
-
input:not([readonly])是静态属性筛选：只要 HTML 里没写readonly就选中，哪怕 JS 已执行el.disabled = true或父级display: none -
input:read-write是运行时 UA 判定：要求元素不仅没readonly，还必须未被禁用、未被遮挡、DOM 中真实可编辑 -
<input readonly>→ 仍匹配:read-only，不匹配:read-write（布尔属性只看存在性，不看值）
想覆盖 contenteditable 元素？别硬套 :read-write
给 div[contenteditable="true"] 加 :read-write 样式，结果必为空。正确路径是绕开伪类，用明确可控的方式：
立即学习“前端免费学习笔记（深入）”；
- 用属性选择器直接定位：
[contenteditable="true"]:focus或[contenteditable]:focus（兼容大小写） - 加 class 统一管理：
<div class="editable">+.editable:focus，JS 切换编辑态时同步增删 class - 避免依赖
:read-write:focus：Safari 直到 iOS 15.4+ 才支持:read-write，旧版直接忽略整条规则
真正容易被忽略的点
当你把样式逻辑全押在 :read-write 上时，其实已经把“可编辑性”这个业务状态耦合进了 CSS。一旦需求变成“点击后才启用编辑”“权限变更后动态开关”或“服务端返回只读标志”，纯 CSS 就彻底失效——这时候必须靠 JS 控制 class，再让样式跟着 class 走，而不是指望伪类能跟上运行时变化。
