HTML文本标签默认样式不一致导致行高、字号、间距错乱，应使用normalize.css而非reset.css修复：它只校准跨浏览器差异（如h1在Chrome/Firefox/IE的margin不同），保留语义和可访问性，默认值更合理，且必须置于所有自定义CSS之前加载。
HTML文本标签的默认样式不一致，直接导致行高、字号、间距错乱
Chrome 的 <h1> 默认 margin-top 是 0.67em，Firefox 是 0.83em，IE6 甚至用像素值（24px）；<p> 在 Safari 中段前距略大，Edge 可能压缩首行缩进。这些差异不是“看起来有点不一样”，而是会导致垂直节奏崩坏、CSS 基于 em 或 rem 的计算全偏移。
不用 reset.css 归零重写——它把所有基础语义都抹平了，反而要手动补 ul 缩进、button 边框、textarea 字体继承等几十处细节。改用 normalize.css：它只修复已知 bug，保留合理默认值，比如维持 <small> 的相对字号、<sub>/<sup> 的垂直对齐逻辑。
normalize.css 必须放在所有自定义 CSS 之前加载，否则它的重置规则会被覆盖。
<strong> 和 <b> 在旧版 IE 中语义丢失但渲染一致，而现代屏幕阅读器行为分化
IE8–IE11 渲染 <strong> 和 <b> 完全一样（加粗），但语义没被解析：AT（辅助技术）不会提高音量或强调语气。这不是样式问题，是 DOM 层面的语义剥离。
立即学习“前端免费学习笔记（深入）”；
更隐蔽的问题在现代浏览器：Chrome 与 Safari 的 VoiceOver 对 <strong> 的语音强调策略不同；若页面用了 font-weight: bold 覆盖默认样式，部分 AT 会直接忽略语义标记。
实操建议：
- 语义优先：表达重要性用
<strong>，仅需视觉加粗用<b> - 避免覆盖
font-weight：如必须定制，用font-variation-settings: 'wght' 700保持可访问性链路 - 禁用
pointer-events: none在<strong>上——某些 AT 依赖事件冒泡定位上下文
<pre> 和 <code> 的空白处理在 IE 与 WebKit 内核间存在解析分歧
IE11 及更早版本对 <pre> 内部的制表符（\t）按 8 字符宽度硬渲染，而 Chrome/Firefox 默认为 4；若内容来自用户输入或 API 返回，\t 在 IE 下可能撑开整行导致横向滚动溢出。
<code> 标签本身无特殊渲染，但常被嵌套在 <pre> 中。问题在于：IE 不支持 white-space: pre-wrap 对 \t 的软处理，且 tab-size CSS 属性在 IE 全系无效。
解决路径：
- 服务端预处理：将输入中的
\t替换为<span style="display:inline-block;width:4ch"></span> - 前端降级：检测
'tabSize' in document.documentElement.style，不支持则用 JS 动态替换\t - 避免纯 CSS 方案：不要依赖
tab-size: 4作为唯一控制手段
<hr> 的语义弱化与样式失控在移动端和旧 IE 中尤为明显
<hr> 本意是“主题分隔”，但 IE8–IE10 把它当 border-bottom 渲染，无视 height；Chrome 110+ 开始默认用 border: none + background 实现，导致老式 reset 规则（如 hr { height: 1px; border: 0; background: #ccc; }）在新 Chrome 下失效。
更麻烦的是语义退化：多数 CMS 输出的 <hr> 实际只是视觉分隔线，但辅助技术仍会播报“horizontal rule”，打断阅读流。WCAG 2.1 明确建议：若无主题切换意义，应改用 <div role="separator" 或 CSS border。
关键动作：
- 检查是否真需要语义分隔：纯装饰线一律不用
<hr> - 若保留，必须设
role="none"或aria-hidden="true"阻断 AT 干扰 - 兼容写法：用
hr { border: 0; height: 1px; background: currentColor; opacity: 0.3; }，避免依赖border-style
最易被忽略的点：文本标签的兼容性问题从来不在“能不能显示”，而在“是否被正确解释”——DOM 结构完整、样式可预测只是下限；语义传达准确、辅助技术可操作、缩放后仍可读，才是真实兼容的终点。别只盯着 DevTools 里元素是否渲染出来，多开一次 VoiceOver，多切一次 200% 缩放，问题才真正浮出水面。
