比更适合会议议程，因其原生表达顺序语义，支持start、type及嵌套，提升可访问性与seo；错误嵌套或省略闭合标签会破坏解析逻辑。
用 <ol></ol> 包裹 <li> 就能展示会议议程，但直接套用默认样式常导致编号错乱、嵌套混乱或语义不清晰——关键不在“能不能显示”，而在“浏览器是否理解这是议程”。
为什么 <ol></ol> 比 <ul></ul> 更适合会议议程
会议议程有明确先后顺序（如“开场→主题发言→茶歇→分组讨论”），<ol></ol> 告诉浏览器和辅助技术“这个顺序不可颠倒”，而 <ul></ul> 仅表示并列关系。搜索引擎、屏幕阅读器会据此提升可访问性与 SEO 权重。
- 用
<ul></ul>写议程：编号靠 CSS 模拟，语义丢失，键盘导航时可能跳过逻辑层级 - 用
<ol></ol>写议程：原生支持start、reversed、type，且可被<li>的value属性逐项微调 - 嵌套议程（如“主题发言”下含“张三｜AI趋势”“李四｜政策解读”）必须用
<ol></ol>套<ol></ol>或<ul></ul>，不能混在<p></p>里硬换行
start 和 type 属性怎么配合议程跳号与格式
实际会议议程常出现“从第3项开始”“用字母标子议题”等需求，仅靠 CSS 无法可靠还原语义。
-
start="3"：让编号从 3 开始，适用于接续上一场会议的议程延续，例如：<ol start="3"><li>分组讨论</li></ol> -
type="A"：主议程用数字，子议题用大写字母，例如：<ol type="A"><li>数据安全合规</li></ol> -
type="i"：用于附录类小节（如“i. 参会须知”），注意小写i表示小写罗马数字，大写I表示大写 - 多个属性可共存：
<ol start="2" type="a"></ol>→ 输出 a, b, c… 从第二项起
嵌套议程时 <li> 内部还能再用 <ol></ol> 吗
可以，而且推荐——但必须确保每个 <li> 是 <ol></ol> 的直接子元素，否则 HTML 解析会出错或降级为普通文本。
- ✅ 正确嵌套：
<ol><li>主题发言<ol><li>张三｜AI趋势</li></ol> </li></ol> - ❌ 错误写法：
<ol> <li>主题发言</li> <ol><li>张三｜AI趋势</li></ol> </ol>（第二个<ol></ol>不在<li>内，语义断裂） - 嵌套层级超过 3 层易降低可读性，建议用 CSS 控制缩进而非依赖 HTML 层级
- 若子项需不同编号类型（如主议程用 1. 2.，子项用 1.1 1.2），应改用 CSS
counter-reset/counter-increment，HTML 仍保持扁平<ol></ol>
容易被忽略的兼容性与可访问性细节
多数人只关注“看起来像不像议程”，但真正影响用户的是解析逻辑。
-
<li>必须闭合：写成<li>开场</li> <li>发言</li>会导致第二项脱离列表上下文，部分屏幕阅读器会跳过 - 不要用
<pre class="brush:php;toolbar:false;"></pre>包<ol></ol>：资料里那个“会议通知”示例用了<pre class="brush:php;toolbar:false;"></pre>，会禁用所有列表语义，浏览器当纯文本处理 - 避免在
<li>里塞<div> 或 <code><p></p>再包内容：这会让辅助技术重复播报“列表项”+“段落”，干扰节奏 - 如果议程含时间（如“09:00–09:30 开场”），把时间用
<time datetime="09:00">09:00–09:30</time>包裹，增强机器可读性
