不该用customelements.define()做导航栏主体，因为是html5标准语义元素，原生支持可访问性；而自定义标签如默认无语义、无焦点管理、不参与tab顺序，需手动实现role、tabindex等才能达标，徒增复杂度且易破坏可访问性。
直接用 <nav></nav> + <ul></ul> + <li> 是最稳妥、语义清晰且可扩展的起点，不用自定义元素（custom element）也能做到结构清晰、样式可控、JS 交互自由。强行用 class 或 data- 属性模拟“自定义元素”，反而增加维护成本，还可能破坏可访问性。
为什么不该用 customElements.define() 做导航栏主体
导航栏本质是语义化导航区域，不是封装逻辑的 UI 组件。浏览器原生 <nav></nav> 已被所有屏幕阅读器识别，而自定义标签如 <my-navbar></my-navbar> 默认无语义、无焦点管理、不参与 tab 键顺序 —— 除非你手动实现 role="navigation"、tabindex、键盘事件等，否则等于主动放弃可访问性。
-
<nav></nav>是 HTML5 标准语义元素，无需 JS 即可被辅助技术理解 - 自定义元素需显式定义
observedAttributes和attributeChangedCallback才能响应aria-expanded等状态变化，徒增复杂度 - 多数 CMS 或静态站点生成器（如 Hugo、Jekyll）不支持运行时注册自定义元素，部署即失效
真正需要“可扩展”的地方：嵌套菜单与状态控制
可扩展性体现在多级下拉、响应式折叠、当前页高亮这些行为上，而不是标签名本身。关键在结构设计和 JS 控制逻辑。
- 二级菜单必须用嵌套
<ul></ul>，且父<li>加class="dropdown"或aria-haspopup="true" - 用
aria-expanded控制显隐，而非仅靠 CSSdisplay: none—— 这样屏幕阅读器才能感知状态变化 - 点击/键盘触发时，优先用
click+keydown（Enter/Space），不要只依赖hover—— 移动端和键盘用户才不会卡住
aria-current="page" 比 class 更可靠地标识当前页
很多教程教你在当前链接加 class="active"，但 class 名易冲突、难维护，且对辅助技术无意义。原生 ARIA 属性才是标准解法。
- 服务端渲染或构建时，直接给对应
<a></a>加aria-current="page" - CSS 中用
a[aria-current="page"] { font-weight: bold; color: #007bff; }即可样式化 - JS 中可通过
document.querySelector('a[aria-current="page"]')定位，比查.active更精准
真正的可扩展瓶颈不在标签怎么写，而在如何让嵌套菜单在小屏下收起、键盘操作不中断、焦点不丢失 —— 这些都需要原生语义打底，再叠加轻量 JS 控制，而不是用自定义元素绕开标准。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
