直接写错误，因其放弃html语义化，导致可访问性缺失、seo弱化、协作成本上升及自动化检查失效，而原生传达结构含义，是工程规范落地的起点。
为什么直接写 <div class="header"> 是错的
<p>因为这不是语义错误，而是协作断层的起点。当多个开发者都用 <code><div class="header"> 替代 <code><header></header>，后续想加无障碍支持、SEO优化或自动化检查时，就得全局 grep 替换+人工验证——成本远高于写对第一行。
- 浏览器不报错，但屏幕阅读器无法识别结构角色，
role="banner" 也得手动补，且容易漏
- HTML Linter（如
htmlhint）默认不校验语义，需显式开启 attr-accessible-headings、require-sibling-h1 等规则
- 团队新人看到
<div class="main">，会自然模仿，规范文档再厚也挡不住“就近复制”惯性
<h3>
<code>lang 属性和 charset 不是可选项
role="banner" 也得手动补，且容易漏htmlhint）默认不校验语义，需显式开启 attr-accessible-headings、require-sibling-h1 等规则<div class="main">，会自然模仿，规范文档再厚也挡不住“就近复制”惯性
<h3>
<code>lang 属性和 charset 不是可选项它们是强制解析层控制点，不是装饰性配置。缺一不可，且顺序敏感。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
必须首行；<code>必须紧随其后；<meta charset="utf-8">必须在<title></title>之前- 如果
charset写在<title></title>后，部分浏览器会先按默认编码（如 ISO-8859-1）解析前几字节，导致标题乱码，且无法回滚 -
lang="zh"和lang="zh-CN"在语音合成工具中表现不同：前者可能调用通用中文库，后者能触发带地域口音的播报（如粤语区设备优先选 Cantonese TTS）
如何让规范不沦为 Wiki 里的摆设
靠文档驱动不了行为，靠工具链才能卡住出口。关键不是“写什么”，而是“不让错的过线”。
- 在
package.json的"scripts"中加入"lint:html": "htmlhint src/**/*.html --config .htmlhintrc"，并确保 CI 流程中npm run lint:html失败即中断构建 -
.htmlhintrc至少启用：doctype-first、id-unique、head-script-disabled、attr-no-duplication - VS Code 安装
HTMLHint插件，并配置工作区设置"htmlhint.options": { "rules": { "tagname-lowercase": true } }，实时标红<div> <li>禁止在 <code>pre-commit钩子中只跑格式化（如 Prettier），必须包含语义校验——格式正确 ≠ 结构正确 - 语义标签和 ARIA 属性必须配套：用了
<nav></nav>就该配aria-label或aria-labelledby；用了<time datetime></time>就不能省略datetime值 - 所有
<img>必须有alt，但空字符串alt=""和缺失alt在 axe-core 检测中是两类问题：前者是装饰图，后者是严重可访问性缺陷 - 团队一旦接受
<section></section>，就必须明确定义它的使用边界——它不是<div> 的高级替代品，而是“有标题的独立主题区块”，否则很快退化为语义垃圾桶 </div>
最容易被忽略的工程化细节
不是规则本身难，而是规则之间存在隐性依赖。比如你要求用 <button></button> 而非 <div onclick>，但没同步约束 CSS 的 <code>cursor: pointer 和 user-select: none，结果开发为“看起来像按钮”而硬套 div，审查时只能肉眼抓。
