del标签的datetime属性必须为ISO 8601格式的UTC时间（如2024-05-20T14:30:00Z）或带时区偏移的完整时间（如2024-05-20T14:30:00+08:00），仅日期或错误格式将被忽略，且该属性仅为元数据，不触发任何默认行为。
del 标签的 datetime 属性怎么写才合法
del 标签的 datetime 属性必须是符合 ISO 8601 标准的完整日期时间字符串，且只能是 UTC 时间（带 Z）或带时区偏移（如 +08:00），不能只写日期或随便填个时间格式。
常见错误是直接写 2024-05-20 或 2024/05/20 14:30 —— 浏览器会忽略该属性，开发者工具里也看不到它生效。
-
datetime值必须是字符串，不是 JavaScriptDate对象或毫秒数 - 推荐用 UTC 格式：例如
2024-05-20T14:30:00Z（注意T和Z不可省略） - 若用本地时间，需显式标注偏移：例如北京时间得写成
2024-05-20T14:30:00+08:00，不能写+8或GMT+8 - 秒可以省略，但最小粒度到分钟时仍需补
:00，比如2024-05-20T14:30:00+08:00合法，2024-05-20T14:30+08:00不合法（缺少秒）
为什么加了 datetime 却没效果
加了 datetime 属性本身不会触发任何 UI 变化或行为 —— 它纯粹是元数据，供辅助技术（如屏幕阅读器）或后续 JS 解析使用。浏览器默认不展示、不校验、也不报错。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
如果你期望“显示删除时间”或“自动高亮过期内容”，得自己写 JS 提取 del[datetime] 并处理，比如：
立即学习“前端免费学习笔记（深入）”；
document.querySelectorAll('del[datetime]').forEach(el => {
const dt = new Date(el.dateTime); // 注意是 el.dateTime（DOM 属性），不是 el.getAttribute('datetime')
if (!isNaN(dt.getTime()) && dt < new Date()) {
el.style.opacity = '0.6';
}
});
-
el.dateTime是只读 DOM 属性，自动解析为Date对象；getAttribute('datetime')返回原始字符串 - 服务器端渲染时，如果时间来自数据库，务必确保输出的是 ISO 字符串，而非 PHP 的
date('Y-m-d H:i:s')这类无T无偏移的格式 - 某些 CMS 或 Markdown 解析器会过滤掉
datetime属性，需检查最终 HTML 源码是否真存在该属性
datetime 在实际项目中容易被忽略的细节
这个属性几乎没人主动读取，但它在语义化和可访问性层面有真实价值：WCAG 要求对时间敏感的变更提供明确时间戳，del + datetime 就是标准做法。
- 搜索引擎可能利用该字段理解内容时效性，尤其在新闻、政策、价格页等场景
- 自动化测试工具（如 axe）会检查
del是否缺失datetime，标记为“低严重性”问题 - 不要用它替代业务逻辑时间字段——后端 API 和数据库仍需独立存删改时间，HTML 层只是同步呈现
- 如果时间来自用户输入，别手动拼接字符串，用
new Date().toISOString()获取 UTC，或Intl.DateTimeFormat输出带偏移的格式
toISOString()，贴进 HTML 就完事。其他地方指望不上它自动干活，但漏掉它，语义就缺了一角。 
