Light DOM — Accessibility & CSS

好，我们来看一下 Light DOM 一个特别突出的优点，就是它打破了 ID 的隔离，这对可访问性的提升有很大的帮助。 你可以先回想一下经典的 Shadow DOM，它就像一个封闭的小房间，每个组件里自己的 ID 都只在这个房间里有效。也就是说，一个组件的按钮，它的 ID 是没办法被另一个组件里的标签引用到的。但 Light DOM 就不一样了，它的元素都直接放在整个页面的共享文档里，ID 是全局可见的。这就允许我们在两个不同的组件之间，建立像 aria-labelledby 这样的 ARIA 关联。比如，一个组件里的标题，可以直接用它自己的 ID，去给另一个组件里的某个区域做标签说明，浏览器或屏幕阅读器就能正确理解它们的关系，让无障碍访问更顺畅。 再说到 CSS 部分，Light DOM 也带来了更自然的表现。在 Shadow DOM 里，外面父母组件的样式，默认是穿透不到影子里的。但在 Light DOM 中，样式可以像我们熟悉的普通网页那样，从父组件自然地“流”下来，也就是级联。父组件的样式表里定义的规则，会直接作用到 Light DOM 子组件的内部元素上。 不过这里有个重要的例外，你要注意一下：这种级联特性只有在原生 Shadow DOM 环境下才工作得很好。如果你用的是合成 Shadow——也就是为了兼容老版本浏览器，框架模拟出来的那层影子——目前还有个限制，样式级联到 Light DOM 子组件还不支持。所以，为了能处处享受到这个便利，通常我们更推荐在支持原生 Shadow 的环境中运行。 另外，有时你也许并不希望父组件的样式乱入到子组件里，造成样式泄露。解决这个问题很直接，给 Light DOM 组件单独建一个作用域样式表，也就是文件名以 .scoped.css 结尾的那个。这样一来，组件里的样式就只会影响自己，不会意外地跑出去。 还有一点很关键：Light DOM 组件的渲染顺序，会决定样式表被注入到页面里的先后顺序。因为 CSS 的优先级规则，同样的选择器，谁在后面被声明，谁的权重就更高。所以，如果页面上有多个 Light DOM 组件，它们加载和显示的顺序，就可能默默地影响最终哪个样式生效。开发的时候要记得留心这个顺序，避免出现难以排查的样式覆盖问题。 简单来说，Light DOM 通过共享 ID 空间，让跨组件的无障碍标记成为可能；通过自然的样式级联，简化了父子组件的样式传递；同时，我们也有工具去控制范围，防止泄露。只是要记住，渲染顺序会影响样式特指性，这个得作为一条潜在规则记在心里。