<ins> 是静态语义标签，需手动创建并设置 ISO 8601 UTC 格式 datetime 属性，不可依赖自动包裹；协作中应保留原文、合理配对 <del>，样式需兼顾可访问性，且不参与表单提交与 SEO。
ins 标签不是自动修订工具，它不监听 DOM 变化
很多人一上来就给 contenteditable="true" 的容器加个事件监听，指望用户敲字时自动套上 <ins> —— 这不会发生。<ins> 是静态语义标签，浏览器不会替你做任何“智能包裹”。它只在你手动写入或用 JS 显式创建时才存在。
真实协作场景中，必须自己控制插入时机：
- 监听
input或beforeinput事件，捕获新增字符位置 - 用
document.createElement('ins')创建节点，而非拼接字符串（避免丢失datetime） - 调用
insertBefore或appendChild插入新节点，再用setAttribute('datetime', ...)补时间戳 - 若批量插入多段，每段的
datetime应取各自实际修改时刻，不能全用Date.now()
datetime 属性必须是 ISO 8601，且推荐带时区 UTC
写成 <ins datetime="2026-04-18">新增条款</ins> 看似合法，但语义不完整：缺少时间与偏移，机器无法判断这是本地时间还是服务器时间，跨时区协作时容易错乱。
正确做法是服务端生成时间戳，格式严格为：
立即学习“前端免费学习笔记（深入）”；
<ins datetime="2026-04-18T13:22:45Z">用户需完成实名认证</ins>
注意点：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 客户端 JavaScript 生成的
new Date().toISOString()可用，但前提是业务允许以客户端时间为依据 - 若服务端渲染（如 SSR 或静态生成），必须用服务端当前时间，否则审计时无法对齐日志
- 旧版 IE 不支持
datetime解析，但现代浏览器（Chrome/Firefox/Safari/Edge）均能读取并传递给屏幕阅读器
和 搭配使用时，别强行“成对”或“嵌套”
常见错误是把 <del> 和 <ins> 当作原子替换单元，比如写成：
<p>原内容 <del>旧条款</del><ins>新条款</ins></p>
这本身没问题，但若旧内容已被物理删除，只剩 <ins>新条款</ins>，就不该硬补一个空 <del>。语义上，<del> 表示“此处曾有、现已移除”，不是占位符。
协作编辑中更合理的做法：
- 保留原始文本，仅用
<del datetime="...">标记被删部分 - 在合理位置插入
<ins datetime="...">，不强求紧邻<del> - 多人同时编辑时，
cite属性可指向具体工单 URL（如cite="https://jira.example.com/issue/PROJ-123"），比注释更结构化
样式可改，但别只靠颜色，也别去掉所有视觉提示
默认下划线在深灰背景或细字体下几乎看不见，确实需要覆盖。但改完后如果只剩红色文字，视障用户通过屏幕阅读器只能听到“插入”，却看不到任何视觉反馈，等于语义断连。
安全的自定义方式：
- 保留
text-decoration，至少用wavy underline或solid underline - 叠加
background-color: rgba(255, 255, 0, 0.2)做高亮，但透明度别低于 0.15，否则失效 - 禁用
text-decoration: none后，必须补图标（如伪元素::after { content: "✎"; }）或 aria-label - 不要给
<ins>绑定click事件——它不触发任何原生事件，加了也没用
真正容易被忽略的是：<ins> 不参与表单提交、不影响 SEO 权重、也不改变 DOM 结构逻辑。它只是告诉世界“这段文字是后来加的”，仅此而已。用错地方，就只剩一条没人注意的下划线。
