CSS伪类:read-only与:read-write_只读状态的样式美化

:read-only仅匹配具有readonly属性的可编辑表单元素；它不响应contenteditable或disabled，且在shadow dom中需显式穿透。

怎么判断一个元素真正触发 :read-only？

浏览器只认 DOM 属性 readonly（布尔属性），不看 contenteditable="false" 或 disabled，也不管 js 是否锁了输入逻辑。哪怕你用 input.setAttribute('readonly', 'readonly')，只要属性存在，:read-only 就生效；删掉就失效。

• textarea、input[type="text"]、input[type="email"] 等可编辑表单控件才支持该伪类，div 或 span 加 readonly 属性无效
• contenteditable="true" 的元素即使设了 readonly，也不会匹配 :read-only —— 它走的是 [contenteditable="false"] 的 css 逻辑
• 注意 safari 15.4 之前对 :read-only 在 input[type="number"] 上的支持有 bug，会漏匹配

:read-write 和 input:not([readonly]) 有什么区别？

表面看都“不是只读”，但语义和覆盖范围完全不同：:read-write 是 UA 判定的“当前可编辑状态”，而 input:not([readonly]) 只是检查属性是否存在。

• :read-write 对没有 readonly 属性但被 JS 禁用（如 el.disabled = true）的元素**不生效** —— 它不等于“可写”，而是“未被声明为只读且未被禁用”
• input:not([readonly]) 会匹配所有没写 readonly 的 input，哪怕它被 disabled 或 contenteditable="false" 控制着
• 想样式区分“真正能输内容”的输入框？优先用 :read-write；只想按 HTML 属性筛，用属性选择器更稳

为什么给 textarea 加 :read-only 样式没反应？

常见原因是用了内联样式或 !important 覆盖了伪类规则，或者父级设置了 pointer-events: none 导致鼠标事件被拦截，视觉上像“没生效”，其实是交互被掐断了。

• 确保 CSS 优先级足够：伪类选择器权重是 0,1,0，比标签选择器高，但低于 class 或 id；别让 textarea { color: #333; } 直接盖掉 textarea:read-only { color: #999; }
• :read-only 不影响 tabindex 或焦点行为，如果元素无法获得焦点，不是伪类问题，是 tabindex="-1" 或 aria-hidden 干的
• chrome 115+ 开始，:read-only 在 Shadow DOM 内部默认不穿透，需显式加 ::slotted(input:read-only) 或用 :host(:has(input:read-only))

兼容性与渐进增强怎么兜底？

IE 完全不支持这两个伪类，edge 12–18 支持但有渲染延迟；现代项目若需兼容到 ios 14.5 以下，得靠 JS 检测 + class 注入。

立即学习“前端免费学习笔记（深入）”；

• 简单兜底：用 input[readonly] 和 input:not([readonly]) 写两套规则，再用 @supports selector(:read-only) 包一层覆盖，老浏览器自动降级
• JS 检测示例：if (CSS.supports('selector(:read-only)')) { /* 加载伪类样式 */ } else { document.querySelectorAll('input[readonly]').foreach(el => el.classList.add('is-readonly')) }
• 别依赖 :read-only 做权限控制 —— 它纯属表现层，用户删掉 readonly 属性就能绕过，后端仍需校验

伪类本身不改变可编辑性，只响应状态；真正容易被忽略的是：它的匹配结果可能滞后于 JS 修改属性后的重排，尤其在快速 toggle readonly 时，建议加 el.offsetHeight 强制同步或用 requestAnimationFrame 延迟样式应用。