CSS:read-only与:read-write使用解析

本文深入解析了 CSS 伪类 `:read-only` 和 `:read-write` 的用法及其在网页开发中的应用。`:read-only` 用于匹配设置了 `readonly` 属性或 `contenteditable="false"` 的 HTML 元素，而 `:read-write` 则对应未设置 `readonly` 或 `contenteditable="true"` 的元素。文章详细阐述了这两个伪类的区别、适用场景，如表单编辑模式切换、表单验证视觉反馈以及代码展示等。同时，强调了 `disabled` 元素与 `:read-only` 的区别，并提醒开发者注意浏览器的兼容性、`contenteditable` 属性的行为差异以及 CSS 选择器的特异性问题。掌握并合理运用 `:read-only` 和 `:read-write`，能有效提升用户体验，简化样式管理，让网页交互更加流畅。

:read-only 和 :read-write 是CSS伪类，用于根据元素是否可编辑应用不同样式。1. :read-only 匹配设置了 readonly 属性或 contenteditable="false" 的元素；2. :read-write 匹配未设置 readonly 或 contenteditable="true" 的元素；3. disabled 元素不匹配 :read-only，需使用 :disabled；4. 它们可用于表单切换、验证反馈和代码展示等场景；5. 注意兼容性、contenteditable 行为差异及选择器特异性问题。正确使用这些伪类能提升用户体验并简化样式管理。

:read-only 和 :read-write 是 CSS 中非常实用的伪类，它们能让我们根据 HTML 元素是否处于可编辑状态来施加不同的样式。简单来说，就是区分那些只能看不能改的，和那些可以随意输入修改的元素，然后分别给它们“化妆”。

要使用它们，其实逻辑非常直接。当你有一个 input 字段或者 textarea，它们默认是可写的。如果你给它们加上 readonly 属性，它们就变成了只读。而 contenteditable 属性则能让任何元素变得可编辑。 :read-only 会匹配那些用户无法编辑的元素。比如一个设置了 readonly 的 input，或者一个禁用了 contenteditable 的 div。 :read-write 则相反，它匹配那些用户可以编辑的元素。这包括没有 readonly 属性的 input 或 textarea，以及设置了 contenteditable="true" 的元素。

/* 针对只读输入框的样式 */
input:read-only {
    background-color: #f0f0f0;
    border: 1px dashed #ccc;
    cursor: not-allowed;
    color: #666;
}

/* 针对可编辑输入框的样式 */
input:read-write {
    background-color: #fff;
    border: 1px solid #007bff;
    box-shadow: 0 0 5px rgba(0, 123, 255, 0.2);
    color: #333;
}

/* 针对可编辑的div */
[contenteditable="true"]:read-write {
    outline: 2px solid #28a745;
    padding: 8px;
    min-height: 50px;
    background-color: #fff;
}

/* 针对不可编辑的div (虽然通常不会直接用:read-only去匹配contenteditable="false"的div，但理论上可以) */
[contenteditable="false"]:read-only {
    background-color: #f9f9f9;
    border: 1px solid #eee;
    padding: 8px;
    color: #555;
}

这里需要提一下，disabled 属性和 readonly 属性是不同的。disabled 的元素既不能编辑也不能提交，而 readonly 的元素虽然不能编辑，但其值仍会随表单提交。:read-only 伪类是针对 readonly 状态的，而非 disabled。这点有时候会让人有点混淆。

它们到底能用在哪些元素上？

这个问题问得好，因为一开始我总觉得它就只针对 input 和 textarea。但实际上，它的适用范围比我们想象的要广一些，也有些微妙的地方。

最直观的，当然是那些标准的表单元素：

• <input> (除了 hidden, radio, checkbox, button 等本身就不可编辑的类型)
• <textarea>

当这些元素被设置了 readonly 属性时，它们就会被 :read-only 匹配。如果没有设置 readonly，或者 readonly 属性值为 false，那它们就会被 :read-write 匹配。

但更灵活的在于 contenteditable 属性。任何 HTML 元素，只要你给它加上 contenteditable="true"，它就能变成一个富文本编辑器区域。这时候，这个元素就会被 :read-write 匹配。反之，如果 contenteditable="false" 或者没有这个属性（默认就是不可编辑的），那么它理论上就会被 :read-only 匹配。不过，对于默认不可编辑的元素，比如一个普通的 div 或者 p 标签，我们通常不会特意去用 :read-only 来匹配，因为它们本来就不可编辑，直接写样式就行了。这个伪类在 contenteditable 场景下，更多是用来区分 true 和 false 状态。

一个常见的误区是，有人可能会觉得 disabled 的元素也会被 :read-only 匹配。但事实并非如此。disabled 的元素是完全不可交互的，而 readonly 的元素虽然不能修改内容，但仍可以被选中、复制，甚至其值可以被脚本读取并随表单提交。所以，如果你想给 disabled 的元素设置样式，得用 :disabled 伪类，而不是 :read-only。这是个小细节，但在实际开发中，如果混淆了，可能会导致样式不生效。

实际开发中，这些伪类有哪些妙用？

在日常开发中，这两个伪类虽然不算是那种“炫技”的CSS属性，但用得巧了，能极大地提升用户体验和代码的可维护性。

我个人最喜欢的一个场景，就是表单的“查看模式”和“编辑模式”切换。很多后台管理系统都会有这种需求：用户点一个“编辑”按钮，表单字段就从只读状态变成可编辑。以前我们可能需要用JavaScript来回切换好几个class，或者直接操作style。现在，只要切换 readonly 属性或者 contenteditable 属性，CSS就能自动响应。

比如，一个用户资料页面：

    姓名:
    <input type="text" value="张三" readonly id="userName">

    简介:
    <textarea readonly id="userBio">一个热爱前端的普通开发者。</textarea>

    

        CSS JavaScript HTML
    

    编辑

然后CSS可以这样写：

/* 默认只读样式 */
input:read-only, textarea:read-only {
    border: none;
    background-color: transparent;
    cursor: default;
    color: #333;
}

/* 可编辑样式 */
input:read-write, textarea:read-write {
    border: 1px solid #007bff;
    background-color: #fff;
    padding: 5px;
    cursor: text;
}

/* contenteditable的只读和可写样式 */
[contenteditable="false"]:read-only {
    border: 1px dashed #eee; /* 提示区域，但不可编辑 */
    background-color: #f9f9f9;
    padding: 5px;
}

[contenteditable="true"]:read-write {
    border: 2px solid #28a745;
    background-color: #fff;
    padding: 4px;
    min-height: 80px;
}

JavaScript就只需要简单地切换属性：

function toggleEditMode() {
    const userName = document.getElementById('userName');
    const userBio = document.getElementById('userBio');
    const userTags = document.getElementById('userTags');

    if (userName.readOnly) { // 当前是只读模式，切换到编辑
        userName.readOnly = false;
        userBio.readOnly = false;
        userTags.contentEditable = "true";
    } else { // 当前是编辑模式，切换到只读
        userName.readOnly = true;
        userBio.readOnly = true;
        userTags.contentEditable = "false";
    }
}

这样，所有的样式切换都由CSS自动完成，JavaScript只负责逻辑，代码会变得非常清晰。

另一个场景是表单验证时的视觉反馈。当某个字段因为某种原因（比如数据正在加载，或者等待服务器验证结果）暂时不可编辑时，我们可以通过设置 readonly 属性，然后用 :read-only 伪类给它一个灰色的背景或者虚线边框，明确告诉用户“这里现在不能动”。这比直接 disabled 要好，因为 disabled 通常意味着这个字段在当前情境下是完全无效的，而 readonly 只是暂时锁住。

还有，在一些需要展示代码或者配置文件的场景，我们可能会用 <textarea readonly> 来展示内容。这时候，我们可以用 :read-only 给它一个特殊的背景色或者字体样式，让它看起来更像一个代码块，而不是一个普通的输入框。这种细微的视觉区分，能让用户更快地理解元素的用途。

使用时需要注意哪些“坑”？

虽然 :read-only 和 :read-write 用起来很方便，但实际操作中还是有些小“坑”需要我们留意，不然可能会遇到一些预期之外的问题。

首先，浏览器兼容性。虽然这两个伪类在现代浏览器中支持度已经很好了（IE9+，Edge，Firefox，Chrome，Safari都支持），但在一些老旧的浏览器或者特定版本中，可能存在兼容性问题。所以，如果你的项目需要支持非常老的浏览器，最好还是做一下渐进增强或者提供降级方案。不过，对于大多数现代Web应用来说，这已经不是一个大问题了。

其次，是关于contenteditable 的行为。当一个元素被设置为 contenteditable="true" 时，它会变成可编辑的。但如果你把它设为 contenteditable="false"，它就会变成不可编辑。这时候，这个元素会被 :read-only 匹配。但是，如果你仅仅是一个普通的 div，没有设置 contenteditable 属性，它默认就是不可编辑的，它也会被 :read-only 匹配。这听起来有点绕，但关键在于，contenteditable 属性的存在与否，以及它的值，是决定 :read-only 和 :read-write 匹配的关键。对于一个普通的、本来就不可编辑的元素，通常我们不会特意去用 :read-only 来给它加样式，因为那样写CSS可能不够直观。更多时候，我们是在动态切换 contenteditable 状态时，利用这两个伪类来做样式区分。

再来，readonly 和 disabled 的区别，前面也提过，这里再强调一下。:read-only 匹配的是 readonly 状态的元素，而不是 disabled 状态的。disabled 的元素需要使用 :disabled 伪类来匹配。这个区分在表单提交时尤为重要：readonly 的字段值会随表单提交，而 disabled 的字段值不会。所以，如果你想让用户不能编辑某个字段，但又希望它的值能被提交到后端，那么 readonly 才是你的选择，相应的样式控制就用 :read-only。

最后，是CSS选择器的特异性（Specificity）问题。如果你同时定义了针对 input 的普通样式和针对 input:read-only 的样式，那么 :read-only 的样式会因为伪类的存在而具有更高的特异性，从而覆盖普通样式。这通常是我们期望的行为，但如果你的CSS结构比较复杂，或者有其他更具体的选择器（比如ID选择器），就可能出现样式不按预期生效的情况。这时候，就需要检查选择器的特异性，确保你的 :read-only 或 :read-write 样式能够被正确应用。

总的来说，这两个伪类虽然简单，但背后涉及的HTML属性和浏览器行为还是有些细节的。理解这些，能帮助我们更高效、更准确地利用它们来优化页面

到这里，我们也就讲完了《CSS:read-only与:read-write使用解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！