1. 从“Expert HTML”说起：XHTML到底想解决什么问题
第一次看到“XHTML – Expert HTML”这个标题，我脑子里冒出来的第一个念头是：这名字起得挺狂。Expert，专家级，凭什么？HTML 这门东西，写个<div>谁不会？但真在项目里滚过几年的人都知道，HTML 写“能跑”和写“专业”之间，隔着一整个太平洋。XHTML 这个项目，本质上就是冲着这个差距去的——它想做的不是又一个语法高亮插件，而是一套把 HTML 从“随手写”拉到“工程化”层面的工具链。
先把概念理清楚。XHTML 在历史上是 HTML 4.01 和 XML 结合的一个规范版本，要求文档必须是良构的 XML——标签闭合、属性加引号、大小写敏感、必须有根元素。后来 HTML5 出来了，XHTML 作为独立规范基本退场，但它的那套“严格性”思想被吸收进了现代前端工程。这个项目叫 XHTML，我理解它是在借这个名号表达一种态度：用 XML 级别的严谨来对待 HTML 的编写、校验和转换。
那它到底能做什么？从标题和热词交叉来看，核心能力大概覆盖这几块：HTML 文档的结构化解析与校验、HTML 到 Markdown 的转换、多 HTML 文件的打包合并、以及围绕 CSS 样式（包括 3D 变换、选择器、字体、动画等）的辅助分析。说白了，它瞄准的是那些天天跟 HTML 打交道、但又被 HTML 的“宽容”坑过的人——比如你写了个页面，浏览器里看着好好的，一到邮件客户端就崩了；或者你有一堆零散的 HTML 片段，想合并成一个文档却总是丢样式。
适合谁来参考？三类人最该看：一是前端新手，正在被“为什么我的 CSS 不生效”折磨；二是做邮件模板、报表导出的后端或全栈，HTML 的兼容性问题是家常便饭；三是任何需要批量处理 HTML 文档的人，比如做内容迁移、文档转换的。这篇文章我会把 XHTML 涉及的核心技术点一个个拆开，从 HTML 基础结构到 CSS 3D 变换，从选择器到打包合并，尽量让不同基础的人都能拿走能直接用的东西。
2. 核心思路拆解：为什么“严格”反而是效率
2.1 宽容的 HTML 与严格的工程需求之间的矛盾
浏览器对 HTML 的宽容是出了名的。你少写一个闭合标签，它帮你补；属性不加引号，它帮你加；大小写混着写，它照样渲染。这种宽容在“快速出个页面”的场景下是优点，但在工程化场景下就是灾难。我踩过最典型的一个坑：用模板引擎生成 HTML 邮件，本地浏览器预览完全正常，发到某些邮件客户端后布局全乱。排查了半天，原因是一个<img>标签没写自闭合，浏览器自动补全了，但邮件客户端的渲染引擎没这么智能，直接把后面的内容吞了。
XHTML 这类工具的核心价值就在这里——它在“写”和“渲染”之间插了一道校验关卡。你写的东西必须先通过严格检查，才能进入下一步。这听起来像是增加负担，但实际上是把调试成本从“运行时”前移到了“编写时”。运行时排查一个布局错乱可能要半小时，编写时被工具提示“第 47 行标签未闭合”只需要三秒。
提示：不要等到页面在目标环境里出问题才去查 HTML 结构。把校验工具接进你的编辑流程，写完就查，比事后救火划算得多。
2.2 解析、校验、转换：一条流水线的三个环节
XHTML 的工作流我理解是三个环节串起来的。第一步是解析，把 HTML 文本读进来，构建成 DOM 树或者类似的结构化表示。这一步的关键是处理 HTML 的各种“不规矩”——比如<br>和<br/>都要能认，属性单引号双引号都要能处理。第二步是校验，对照一套规则检查结构是否合法，比如标签嵌套是否正确、必需属性是否缺失、ID 是否重复。第三步是转换或输出，根据目标格式（Markdown、合并后的单文件、格式化后的 HTML）做相应处理。
这三个环节里，解析是最容易被低估的。很多人觉得“读个 HTML 有什么难的”，但真自己写一个解析器就知道，HTML 的容错规则多到令人发指。比如<p>标签里不能再嵌套<p>，浏览器遇到这种情况会自动闭合前一个，你的解析器如果不知道这条规则，构建出来的树就是错的。XHTML 项目如果要做得好，解析层必须把这些边界情况都覆盖到。
2.3 为什么选择“专家级”定位而不是“入门友好”
市面上不缺 HTML 入门工具，格式化、高亮、简单校验，一抓一大把。XHTML 打“Expert”这张牌，我猜是想抓住那些已经过了入门阶段、但又被工程问题卡住的人。这群人的特点是：不需要你教他<div>是什么，但他需要知道为什么他的 CSS 3D 旋转在某个浏览器里方向反了，或者为什么打包多个 HTML 后样式全丢了。
这个定位决定了工具的设计取向——它不会把东西藏起来，而是把细节暴露给你。比如 CSS 的transform: rotateY(60deg) translateZ(300px)，入门工具可能只告诉你“这是 3D 旋转”，但专家级工具会告诉你旋转方向的正负判断规则、透视距离对视觉效果的影响、以及在不同坐标系下的表现差异。这种“把底层逻辑摊开”的做法，对目标用户来说才是真正有价值的。
3. HTML 基础与文档结构：那些你以为会了其实没会的东西
3.1<!DOCTYPE html>不只是一行声明
热词里反复出现<!doctype html> <html lang="zh-cn"> <head> <meta charset="utf-8">这一串，说明很多人对这个文档头部的理解还停留在“复制粘贴”阶段。我见过不少项目，lang属性写的是zh-cn，但页面里混着英文内容；charset写的是utf-8，但文件实际保存成了 GBK。这些细节在简单页面里可能不出问题，一旦涉及多语言、SEO 或者字符处理，就是隐藏的雷。
<!DOCTYPE html>的作用是告诉浏览器用标准模式渲染，而不是怪异模式。怪异模式是什么？简单说就是浏览器为了兼容上世纪的老页面，故意用一套“不标准”的规则来渲染。你在怪异模式下写的 CSS，盒模型的计算方式都和标准模式不一样。所以这行声明不是可有可无的装饰，它直接决定了你后面所有 CSS 的基准。
lang属性影响的不只是屏幕阅读器。它会影响浏览器的字体选择（中文和日文共用一些汉字，但字形不同）、拼写检查、以及某些 CSS 属性（比如hyphens断词规则）的行为。写zh-cn还是zh-hk还是zh，在涉及字体渲染时是有实际差异的。
charset必须放在<head>的最前面，最好在<title>之前。原因是浏览器需要先知道编码方式，才能正确解析后面的内容。如果charset声明晚了，浏览器可能已经用默认编码解析了一部分内容，导致乱码。
3.2 标签闭合与嵌套：浏览器帮你补的，工具不会帮你补
HTML5 里有些标签是可以省略闭合的，比如<li>、<p>、<td>。浏览器会根据上下文自动推断闭合位置。但这套推断规则很复杂，而且不同浏览器的实现可能有细微差异。XHTML 的严格模式要求所有标签必须显式闭合，这看起来是“倒退”，实际上是消除了歧义。
嵌套规则也是重灾区。<p>里不能放<div>，<a>里不能放另一个<a>，<ul>的直接子元素只能是<li>。这些规则浏览器大多会“帮你处理”，但处理方式未必是你想要的。比如你在<p>里写了个<div>，浏览器会把<p>提前闭合，然后<div>变成<p>的兄弟节点而不是子节点。你的 CSS 选择器如果是p > div，就永远选不中。
注意：用校验工具跑一遍你的 HTML，把所有“浏览器帮你修”的地方都改成显式正确的写法。这个习惯能省掉大量跨浏览器调试时间。
3.3 HTML 转 Markdown：转换过程中的信息损失与保留
热词里有“html转为md”，这是个很实际的需求。做文档迁移、博客搬家、README 生成的时候经常遇到。但 HTML 转 Markdown 不是无损的，因为 Markdown 的表达能力比 HTML 弱。比如 HTML 里的<div class="warning">在 Markdown 里没有直接对应，只能转成引用块或者加粗文本。
转换的核心难点在于：哪些 HTML 标签有 Markdown 对应，哪些没有。<h1>到<h6>对应#到######，<strong>对应**，<em>对应*，<a>对应[]()，<img>对应![]()，<ul>/<ol>/<li>对应列表语法。但<table>的转换就很麻烦，因为 Markdown 的表格语法不支持合并单元格、不支持复杂的嵌套。<div>和<span>这类纯样式容器，转换时通常直接丢弃标签只保留内容。
XHTML 如果要做 HTML 到 Markdown 的转换，我建议的策略是：先解析成 DOM 树，然后递归遍历，对每个节点判断是否有 Markdown 对应。对于没有对应的节点，根据其语义角色决定处理方式——是保留内容丢弃标签，还是转换成最接近的 Markdown 结构。代码块的处理要特别小心，<pre><code>里的内容必须原样保留，不能做任何转义或格式化。
4. CSS 核心机制：从选择器到 3D 变换的实战解析
4.1 选择器优先级：为什么你的样式“不生效”
CSS 选择器是热词里出现频率最高的内容之一。很多人写 CSS 的困惑不是“怎么写”，而是“为什么我写了但不生效”。这背后 90% 的情况是优先级问题。CSS 优先级的计算规则是：行内样式 > ID 选择器 > 类选择器/属性选择器/伪类 > 元素选择器/伪元素。同一级别内，后写的覆盖先写的。
但实际项目里还有两个容易被忽略的因素：!important和继承。!important会直接打断正常的优先级计算，除非另一个规则也用了!important且优先级更高。继承则是说某些属性（比如color、font-size）会从父元素传给子元素，但另一些属性（比如margin、padding、border）不会。如果你给父元素设了color: red，子元素没设color，那子元素就是红色；但如果你给父元素设了margin: 20px，子元素不会自动获得这个 margin。
排查优先级问题有个笨办法但很有效：在浏览器开发者工具里选中元素，看 Computed 面板里最终生效的是哪条规则，然后看 Styles 面板里被划掉的规则，就能知道是哪条规则赢了。
4.2 CSS 3D 旋转：rotateY(60deg) translateZ(300px)到底发生了什么
这个表达式在热词里被单独拎出来问，说明很多人对它的实际效果感到困惑。我来拆解一下。transform属性里的多个函数是从右往左应用的，所以先执行translateZ(300px)，再执行rotateY(60deg)。
translateZ(300px)是沿 Z 轴（垂直于屏幕向外）移动 300 像素。在没有设置perspective的情况下，这个移动在视觉上是没有效果的，因为正交投影下 Z 轴位移不改变元素在屏幕上的位置和大小。但一旦父元素或自身设置了perspective，Z 轴位移就会产生“近大远小”的效果——元素向观察者靠近，看起来会变大。
rotateY(60deg)是绕 Y 轴（垂直轴）旋转 60 度。正角度是顺时针方向（从 Y 轴正方向往原点看）。旋转后，元素的右侧会向屏幕内转，左侧向屏幕外转。如果配合了perspective，你会看到元素呈现出一个立体的倾斜效果。
正负判断的核心规则：rotateY正角度让元素右侧向后转（远离观察者），负角度让右侧向前转（靠近观察者）。rotateX正角度让元素顶部向后转，负角度让顶部向前转。rotateZ正角度是顺时针旋转，负角度是逆时针。
提示：调试 3D 变换时，先加一个明显的
perspective值（比如 800px），然后单独调一个旋转轴，观察效果后再叠加其他变换。一次性写一长串 transform 函数，出了问题很难定位是哪个环节的错。
4.3 字体渐变与换行省略：两个高频需求的实现细节
CSS 字体渐变（background-clip: text配合background-image）是个视觉效果很好的技巧，但有个坑：必须设置-webkit-background-clip: text和-webkit-text-fill-color: transparent才能在 WebKit 内核浏览器里生效。而且如果文字有换行，渐变会应用到整个文本块而不是每行单独渐变。
换行省略（text-overflow: ellipsis）需要三个属性配合：white-space: nowrap、overflow: hidden、text-overflow: ellipsis。少一个都不行。多行省略在纯 CSS 里比较麻烦，通常用-webkit-line-clamp配合display: -webkit-box来实现，但兼容性有限。
4.4 鼠标移入事件与涟漪光圈扩散
css 鼠标移入事件通常指的是:hover伪类，但热词里可能也涉及 JavaScript 的mouseenter/mouseover。两者的区别是：mouseover会在子元素之间冒泡触发，mouseenter不会。做涟漪扩散效果时，通常用:hover配合::after伪元素和transform: scale()动画来实现。
涟漪效果的核心是：一个圆形的伪元素初始scale(0)，hover时scale(1)并配合opacity变化。要让它从鼠标位置扩散，需要用 JavaScript 计算鼠标坐标并设置transform-origin。纯 CSS 只能从元素中心扩散。
5. 实操过程：从零搭建一个 HTML 处理流程
5.1 环境准备与工具选型
如果你要复现 XHTML 这类工具的核心功能，我建议的技术栈是 Node.js 加几个关键库。解析用parse5或htmlparser2，前者更符合 HTML5 规范，后者性能更好。校验可以用html-validate，它支持自定义规则集。HTML 转 Markdown 用turndown，这是目前最成熟的方案。打包合并的话，自己写一个基于 DOM 遍历的合并逻辑就行，不需要太重的依赖。
编辑器方面，VS Code 加几个插件就够了：HTML CSS Support 提供类名提示，Prettier 做格式化，HTMLHint 做实时校验。如果你在 Ubuntu 下工作，这些插件都有 Linux 版本，安装没有额外门槛。
5.2 解析与校验的代码实现
先装依赖：
npm init -y npm install parse5 html-validate turndown解析 HTML 并输出 DOM 树结构：
const parse5 = require('parse5'); const fs = require('fs'); const html = fs.readFileSync('input.html', 'utf-8'); const document = parse5.parse(html); function walk(node, depth = 0) { const indent = ' '.repeat(depth); if (node.tagName) { console.log(`${indent}<${node.tagName}>`); } if (node.childNodes) { node.childNodes.forEach(child => walk(child, depth + 1)); } } walk(document);校验的话，html-validate可以直接对文件跑：
npx html-validate input.html它会输出所有不符合规则的地方，包括未闭合标签、重复 ID、缺失 alt 属性等。你可以根据项目需求配置.htmlvalidate.json来调整规则严格程度。
5.3 HTML 转 Markdown 的完整流程
turndown的基本用法很简单：
const TurndownService = require('turndown'); const turndownService = new TurndownService({ headingStyle: 'atx', codeBlockStyle: 'fenced' }); const markdown = turndownService.turndown(html); console.log(markdown);但实际项目里需要自定义规则。比如你想把<div class="note">转成引用块：
turndownService.addRule('note', { filter: (node) => node.nodeName === 'DIV' && node.classList.contains('note'), replacement: (content) => `> ${content}\n` });表格的转换需要额外处理，因为turndown默认对表格的支持有限。你可能需要自己写一个规则，把<table>转成 Markdown 表格语法，同时处理表头、对齐、合并单元格等情况。
5.4 多 HTML 文件打包合并
打包多个 HTML 的核心逻辑是：提取每个文件的<body>内容，按顺序拼接，然后处理样式和脚本的合并。样式合并要注意选择器冲突——如果两个文件都定义了.title，合并后后面的会覆盖前面的。解决方案是给每个文件的样式加一个命名空间前缀，或者用 Shadow DOM 隔离。
const files = ['page1.html', 'page2.html', 'page3.html']; const bodies = files.map(f => { const doc = parse5.parse(fs.readFileSync(f, 'utf-8')); const body = doc.childNodes.find(n => n.tagName === 'body'); return parse5.serialize(body); }); const merged = `<!DOCTYPE html> <html lang="zh-cn"> <head><meta charset="utf-8"><title>Merged</title></head> <body>${bodies.join('\n')}</body> </html>`;注意：合并前一定要先校验每个文件的合法性。一个文件里的未闭合标签可能“吞掉”后面所有文件的内容，导致合并结果完全错乱。
6. 常见问题与排查技巧实录
6.1 样式失效问题速查表
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 样式完全不生效 | 选择器写错、文件未加载、优先级被覆盖 | 开发者工具看 Computed 面板 |
| 部分样式生效 | 属性值不合法、浏览器不支持 | 看 Styles 面板是否有删除线 |
| 3D 变换无效果 | 缺少 perspective、transform 被覆盖 | 检查父元素 perspective 和自身 transform |
| 字体渐变不显示 | 缺少 -webkit- 前缀 | 补全 background-clip 和 text-fill-color |
| 换行省略不生效 | 缺少 white-space 或 overflow | 三个属性必须同时存在 |
6.2 IE11 打开 CSS 样式失效的排查思路
热词里提到“html网页 ie11打开css样式失效”，这是个经典问题。IE11 对现代 CSS 的支持有限，flexbox的部分属性、grid、CSS 变量、calc()的某些用法都不支持。排查步骤是：先用@supports检测特性支持，然后针对 IE11 写降级样式。如果项目必须支持 IE11，建议用 Autoprefixer 加 PostCSS 来处理兼容性，而不是手写前缀。
6.3 HTML 邮件样式兼容性避坑
HTML 邮件的渲染引擎和浏览器差异巨大。Gmail 会剥离<style>标签里的部分规则，Outlook 用 Word 的渲染引擎，对margin和padding的支持很怪。做邮件模板时，尽量用表格布局而不是 div 布局，样式尽量内联，避免使用flex和grid。图片要加alt和固定宽高，否则在某些客户端里会撑破布局。
6.4 打包后样式丢失的排查
打包多个 HTML 后样式丢失，最常见的原因是<style>标签被合并时去重了，或者选择器冲突导致后面的覆盖了前面的。排查方法是：先单独打开每个源文件确认样式正常，然后逐步合并，每合并一个就检查一次。如果样式是在<head>里用<link>引入的，合并时要确保 CSS 文件路径正确，或者直接把 CSS 内容内联进去。
7. 一些实操心得与后续扩展方向
我在处理 HTML 相关项目时，最大的体会是：不要相信浏览器的“宽容”。浏览器帮你补的每一个标签、帮你修的每一个属性，都是在给你埋雷。XHTML 这类工具的价值不在于它有多复杂，而在于它强迫你把东西写对。写对一次，后面所有环节都省心。
另一个心得是关于 CSS 3D 变换的。很多人觉得 3D 效果“酷炫但难调”，其实核心就三个变量：旋转角度、透视距离、变换顺序。把这三个变量控制住，效果就是可预测的。我通常的做法是先写一个最小的测试页面，只放一个方块，然后逐个调整参数，观察变化，确认理解正确后再应用到实际项目里。
这个项目后续可以扩展的方向不少。比如加一个 CSS 选择器性能分析功能，告诉你哪些选择器可能导致重绘开销大；或者加一个 HTML 可访问性检查，自动检测缺失的alt、aria属性、对比度不足等问题。再或者做一个 HTML 到 JSX 的转换，方便 React 项目迁移。这些方向都围绕同一个核心：让 HTML 的编写从“凭感觉”变成“有依据”。
最后分享一个小技巧：如果你经常需要把 HTML 转成其他格式，建议把转换规则写成配置文件而不是硬编码在代码里。这样换一个项目只需要换配置，不用改代码。turndown支持自定义规则，html-validate支持自定义规则集，把这两者的配置管理好，你的 HTML 处理流程就能复用到大部分场景。
