ol的start属性失效最常见的原因是子元素非li导致dom结构非法，其次为start值类型错误、ie11不支持、css样式覆盖、嵌套结构断裂；正确嵌套和css counters是解决连续编号的关键。

ol 的 start 属性为什么没生效

最常见的原因是把纯文本或 <p></p>、<div> 直接塞进 <code><ol></ol> 里。HTML 规范只允许 <li>（以及少数元数据标签）作为 <ol></ol> 的直接子元素；其他内容会被浏览器忽略，编号逻辑也跟着失效。

另一个高频陷阱是误用 start 值类型：start="c" 或 start="3.5" 不会报错，但浏览器会静默转成整数或回退到 1。想从字母 C 开始？必须写 start="3" 并配 type="a"。

• start 只影响视觉起始值，不改变 DOM 顺序或屏幕阅读器播报逻辑
• IE11 及更早版本完全不支持 start，需用 CSS counter-reset 替代
• 若同时设了 type 和 CSS list-style-type，后者优先，start 仍有效但可能被样式遮盖

嵌套 ol 时编号突然重置为 A 或 1

根本原因不是浏览器 bug，而是 DOM 结构断裂：子 <ol></ol> 没有严格嵌套在父级 <li> 内部，而是放在了外层 后面——这会让浏览器认为它是全新列表，必然重置计数器。

正确结构必须是：每个子 <ol></ol> 都是某个 <li> 的直接子内容，不能“悬空”。

html-to-pptx

将多页 HTML 演示文稿转换为美化的 PPTX 文件，便于分享和分发。

下载

• ❌ 错误：<ol type="A"><li>A. Item</li></ol> <ol type="1"><li>1. Sub</li></ol>
• ✅ 正确：<ol type="A"><li>A. Item<ol type="1"><li>1. Sub</li></ol> </li></ol>
• type 值不区分大小写，但建议统一用小写（type="a"），避免旧浏览器解析异常

跨多个 ol 实现真正连续编号（如 3.1 → 3.2 → 4.1）

start 和 type 在这种场景下完全不够用。必须切换到 CSS counters，因为只有它能跨元素维持状态、拼接层级、并响应 DOM 变化。

核心是用 counters(list-item, ".") ——它复用浏览器内置的 list-item 计数器，自动继承外层 start 值，无需手动 counter-reset。

• 先清空默认样式：ol { list-style-type: none; }
• 对嵌套项加伪元素：ol ol li::before { content: counters(list-item, ".") " "; }
• 注意：外层 <ol></ol> 必须设 start，内层才能继承；且结构必须语义嵌套，否则 counters() 无上级可查

value 属性和 start 混用时的编号逻辑

value 只作用于单个 <li>，它覆盖的是该 <li> 的显示值，后续项仍按“前一项 +1”递增，不感知 start。

当 start 和 value 同时出现，start 仅决定第一个 <li> 的基础值，value 在其上覆盖——但后续项只看前一项的最终显示值，不是 start。

• 例如：<ol start="5"> <li value="10">X</li> <li>Y</li> </ol> → 显示为 10. X、11. Y，不是 5. X、6. Y
• value 对嵌套 <ol></ol> 无效，只影响同级 <li>
• 依赖 value 跳号会影响可访问性，屏幕阅读器可能无法正确映射语义顺序

连续编号最难缠的地方不在语法，而在结构合法性：只要 <ol></ol> 子元素不是 <li>，或子 <ol></ol> 没卡在 <li> 里面，所有属性和 CSS 都救不回来。