:read-write仅匹配三类原生可编辑元素：input（排除hidden/radio/checkbox/file）、textarea、select（safari支持弱）；不匹配contenteditable元素、range/color输入框、button等；匹配仅依赖html属性存在与否，与js状态无关。
哪些元素能被 :read-write 匹配到
:read-write 不是“所有看起来能点能输的都算”，它只认三类原生可编辑元素：<input>（排除 type="hidden"、"radio"、"checkbox"、"file" 等不可文本输入类型）、<textarea></textarea>、<select></select>。注意：<select></select> 在部分浏览器中行为不一致，Chrome 和 Firefox 通常支持，Safari 对其 :read-write 匹配较弱。
常见误判：
-
div[contenteditable="true"]默认不匹配:read-write—— 即使聚焦了也不自动触发，除非你手动加:focus -
input[type="range"]或input[type="color"]虽可交互，但不接受文本输入，多数浏览器不视为:read-write -
button、output、自定义 Web Component 即使绑了事件或 JS 控制，也完全不在:read-write的作用域内
:read-write 的匹配逻辑取决于属性，不是 JS 状态
它只看 HTML 属性是否存在，不响应 JavaScript 动态修改的逻辑状态。比如：
-
<input readonly>→ 不匹配:read-write（布尔属性写法，无值即生效） -
<input readonly>→ 依然匹配:read-only，因为readonly属性存在，值真假无关 -
element.readOnly = false（JS 设置）→ 样式会更新，但前提是该属性原本就存在；如果 DOM 里根本没写readonly，JS 设true再设false才会触发切换 -
oninput="return false"或event.preventDefault()→ 完全不影响:read-write匹配，伪类根本不读这些
和 :disabled、:read-only 共存时的样式优先级
三者语义不同，但渲染时有明确权重顺序：:disabled > :read-only > :read-write。这意味着：
- 如果一个
input同时有disabled和readonly属性，:disabled样式一定生效，:read-only和:read-write都被覆盖 -
:read-only和:read-write是互斥的，但不是穷尽覆盖：比如input[type="hidden"]既不匹配:read-write也不匹配:read-only，它什么伪类都不进 - 别指望用
:read-write“撤销”:read-only的背景色——两个伪类应各自完整定义，而不是靠层叠覆盖
实际用法建议：聚焦态比可写态更可靠
想给用户明确反馈“现在可以编辑”，:read-write:focus 看似合理，但问题不少：
- Safari 直到 iOS 15.4+ 才支持
:read-write，旧版直接失效 -
:read-write本身不带交互反馈（比如 hover、active），仅反映静态可写性 - 真正需要强调“当前活跃”的场景，
:focus更通用、兼容性更好
推荐写法：
input:not([readonly]):not([disabled]):focus,<br>textarea:not([readonly]):not([disabled]):focus {<br> border-width: 2px;<br>}<br>[contenteditable="true"]:focus {<br> border: 2px solid #007bff;<br> outline: none;<br>}
如果你必须区分“可编辑但未聚焦”和“已聚焦”，纯 CSS 无法靠 :read-write 实现——它不响应鼠标悬停，也不反映初始渲染前的状态变化，得靠 class 切换或 JS 监听。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
