与须成对使用以表达修订语义,单独仅具样式效果;需配合datetime(iso 8601)和可选cite属性,用于法律更新、价格调整等需标识变更的场景,不可嵌套或滥用为块级容器。

<ins></ins> 和 <del></del> 必须成对出现才有修订意义,单独用 <ins></ins> 只是加下划线,不构成“修订”语义。
什么时候该用 <ins></ins> 而不是直接写新文本
当你需要让机器(搜索引擎、屏幕阅读器、文档比对工具)知道「这段是后来加的」,而不是「它本来就该在这儿」时,才用 <ins></ins>。比如法律条款更新、产品特性新增、价格调整说明——这些场景里,变更本身是信息的一部分。
常见错误是把 <ins></ins> 当作纯样式标签,只为了加下划线。结果爬虫无法识别内容变更,辅助技术读不出“这是新增”,协作系统也提取不到时间戳。
- 必须配合
datetime属性(ISO 8601 格式,如2026-04-25T14:20:00Z),否则语义残缺 -
cite属性推荐填,指向变更依据(如 PR 链接、政策原文 URL),不是可有可无的装饰 - 不要嵌套
<ins></ins>或<del></del>在<p></p>外层当块级容器用——它们本就是内联元素,包裹段落会触发浏览器隐式修正,导致 DOM 不稳定
<ins></ins> 和 <del></del> 怎么配对才有效
配对不是指物理上相邻,而是逻辑上对应:删除旧内容 + 插入新内容 = 一次修订动作。浏览器不校验是否“一一对应”,但语义解析器(如无障碍工具)依赖这种结构推断意图。
典型电商价格变更写法:
<p>原价:<del datetime="2026-04-20T09:00:00Z">¥299</del> <ins datetime="2026-04-25T14:20:00Z">¥249</ins></p>
注意点:
- 两个标签的
datetime值应不同,且<ins></ins>的时间不能早于<del></del>(否则逻辑矛盾) - 避免在同一个
<ins></ins>里混入未被删除的旧文本,例如<ins>现在还支持实时流处理,且兼容旧API</ins>—— 后半句“兼容旧API”没被<del></del>过,就不该出现在<ins></ins>里 - 如果只是替换一个词(如“快”→“更快”),优先用
<del></del>+<ins></ins>包裹对应位置,而不是整句重写
CSS 样式会影响语义吗
不会。无论你用 CSS 把 <ins></ins> 改成红色粗体、把 <del></del> 改成虚线删除线,甚至设成 display: none,其 HTML 语义仍然存在。但这么做会破坏可访问性——屏幕阅读器仍会读出“已插入”“已被删除”,而用户却看不见视觉提示。
安全做法是保留默认下划线/删除线,仅微调颜色或粗细:
ins { text-decoration: underline; text-decoration-color: #28a745; }<br>del { text-decoration: line-through; text-decoration-color: #dc3545; }
特别注意:text-decoration: none 会抹掉所有下划线和删除线,但不会取消语义,反而造成「语义有、表现无」的割裂,不建议全局禁用。
容易被忽略的兼容性细节
所有现代浏览器都支持 <ins></ins> 和 <del></del>,但老版本 Safari(iOS 12 之前)对 datetime 属性的解析不一致,可能忽略或报错;IE 已淘汰,无需考虑。
真正麻烦的是语义消费端:
- 部分 CMS 导出 PDF 时会丢弃
<ins></ins>/<del></del>,只保留文本,导致修订痕迹消失 - 某些静态站点生成器(如早期 Hugo 版本)默认 strip 掉这些标签,需显式配置白名单
- Word 导入 HTML 时,
<ins></ins>可能被转为“修订模式下的插入”,但cite和datetime元数据大概率丢失
如果修订信息要跨平台留存,别只靠 HTML 标签——得在构建流程里额外导出变更日志 JSON,或用注释标记(如 <!-- INS:2026-04-25 -->)作后备。










