ol标签必须仅包含li直接子元素，纯文本、p或div等会被浏览器忽略并移出；start设整数起始编号（IE支持），reversed实现倒序（仅decimal有效），type切换编号样式但不改语义。

ol 标签本身不直接承载内容，所有可见文本必须包裹在 li 里——这是最常被忽略的硬性规则，不是“建议”，是 HTML 解析器强制执行的结构前提。

为什么 li 必须是 ol 的直接子元素

浏览器解析 ol 时，只识别其直接子节点为 li；其他任何标签（如 p、div、span）或裸文本，都会被自动“提升”到 ol 外部，导致编号断裂、样式错位、屏幕阅读器无法播报层级。

常见错误现象：

• 编号从 1 重新开始（比如第 3 条后突然又出现 “1.”）
• 文字溢出容器、缩进丢失
• 子列表不缩进、不继承父级编号逻辑

正确做法只有一条：把每一段规则、每一个步骤、每一项条款，都明确归入一个 li 中，哪怕它只包含一句话或一个短语。

立即学习“前端免费学习笔记（深入）”；

ol 嵌套必须发生在 li 内部

子 ol 不是挂在主 ol 下，而是必须完整嵌在某一个 li 的起始与结束标签之间。否则，浏览器会把它当作独立列表处理，和父级完全脱钩。

使用场景：

Wechat Article Html

将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。

下载

• 法律条文中的“第34条”下含 a/b/c 款
• 操作指南中“第三步”展开为多个子动作
• 技术文档里某项配置说明附带多条约束条件

参数差异：

• 外层 ol 用 start="34" 控制起始数字
• 内层 ol 用 type="a" 切换标记类型（小写字母）
• 不能混用 type 和 CSS list-style-type 同时控制同一层，优先级易冲突

哪些内容可以合法放在 li 里

li 是容器型元素，允许嵌套几乎所有 HTML 内容，但需注意语义连贯性：

• 纯文本（最常见）
• p、strong、em 等行内或块级文本标签
• 另一个 ol 或 ul（必须完整包裹）
• 表格 table、图片 img、代码块 pre（只要不破坏可访问性）

容易踩的坑：

• 在 li 外写 p 包裹列表项内容（典型反模式）
• 用 div 替代 li 并加类名模拟编号（丧失语义、影响 SEO 和无障碍）
• 给 li 加 display: inline 却没处理 list-style-position，导致编号错位

start 和 reversed 的实际边界

start 是数值型属性，只接受整数（如 start="100"），不能是字符串或带单位；reversed 是布尔属性，仅控制递减逻辑，不改变起始值。

性能与兼容性影响：

• start 在所有现代浏览器中稳定支持，包括 IE11
• reversed 在 Safari 12.1+ 才完全可靠，旧版需降级为手动编号或 JS 补偿
• 二者都不触发重排，但若配合大量嵌套 ol，可能轻微增加 DOM 树深度，对极端长列表需留意渲染延迟

复杂点在于：编号逻辑由浏览器原生维护，一旦结构出错（比如漏了 li 或嵌套错位），就无法靠 CSS 修复——必须回归 HTML 结构本身。很多人卡在这里反复调样式，其实问题早就在第一层 ol 里了。