Angular模拟Shadow DOM是否符合HTML标准？为何采用非标准标记且未受关注？

先明确Angular实现组件样式隔离的两种核心模式：

• ShadowDom 模式：完全贴合HTML标准，用原生Shadow DOM把组件样式锁在宿主元素的shadow根里，生成的代码能轻松通过W3C/WHATWG的标准验证。
• Emulated 模式：这是Angular默认的方案，它不依赖原生Shadow DOM，而是给组件内的DOM元素加_ngcontent-ng-*这类自定义属性，再配合编译后的带属性选择器的样式规则，模拟出样式隔离的效果。

针对你提出的几个疑问，逐一解释：

1. 为什么Angular要用非标准的_ngcontent-ng-*属性？ #

最核心的原因是早期浏览器兼容性。在Angular刚推出的时候，原生Shadow DOM的支持度极低，像旧IE、不少移动端浏览器完全不支持。为了让框架能覆盖更多用户，Angular搞了Emulated这个降级方案——不需要浏览器支持Shadow DOM，照样能实现样式隔离。

另外，选不带data-前缀的属性，也是为了避免和开发者自定义的data属性冲突，同时明确标记这些是Angular内部用的，不会被误当成业务属性来用。

2. 这类非标准属性有没有合理性？ #

严格按W3C规范说，_ngcontent-ng-*确实不符合自定义数据属性要以data-开头的要求，但HTML标准其实允许添加任意自定义属性——只是非data-前缀的属性不属于“标准自定义数据属性”范畴，不会被dataset API处理而已。浏览器对这类属性完全兼容，不会因为有它们就导致页面出问题，只是过不了严格的W3C代码验证。

对Angular团队来说，这是框架内部的实现细节，不是给开发者用的公共API，所以是权衡兼容性和功能后的选择。

3. 为什么这个问题没怎么被关注？ #

• 实际影响太小：虽然不符合验证标准，但这些属性不会影响页面功能和兼容性，绝大多数开发者和测试流程不会因为W3C验证不通过就改方案。
• 原生Shadow DOM普及了：现在主流浏览器都支持原生Shadow DOM了，越来越多项目开始切换到ShadowDom模式，Emulated模式的使用场景在减少，相关疑问自然也少了。
• 开发者更关注功能：大家用Angular主要是看重它的开发效率和生态，很少会盯着框架内部实现的标准性细节，除非刚好遇到必须过W3C验证的特殊需求，否则没人特意纠结这个。

内容的提问来源于stack exchange，提问作者meles