Vaadin组件的产品负责人在这里。您正在问我们多年来一直在问自己的问题：

• 我们应该在多大程度上防止用户用他们的CSS破坏我们的组件，或者防止用户应用定制的CSS，这些CSS很可能会被我们在以后的版本中的实现更改所破坏？
• 我们如何平衡这些防止损坏的尝试和为用户提供定制组件样式的方法的需要？

等等。
在Vaadin 10中，我们最初的方法是在Shadow DOM中尽可能多地隐藏组件的内部结构，并且只将具有部分名称的元素（以及根元素）定义为“公共样式API”的一部分。
然而，这种方法有许多缺点：
1.即使样式仅限于命名部件和根，元素也不会彼此隔离地呈现--应用于影子父级的CSS会影响它们的命名部件子级（在某些情况下，反之亦然！），因此它远不能提供针对非未来安全定制CSS的防弹保护
1.您仍然可以通过这些公开的元素以各种方式破坏组件（尽管您确实需要专门针对它们，因此它确实可以防止样式无意中应用到组件）
1.选择哪些元素应命名为部件是一项困难的平衡操作：太少，你限制定制样式太多;太多，那么shadow DOM样式封装的全部意义就被破坏了
1.事实证明，Shadow DOM确实损害了可访问性和许多很好的浏览器特性，如表单自动完成和密码管理器，所以我们不得不将一些元素从shadow移到slot中，从而将它们完全暴露给自定义CSS。
今天，我对这件事的看法是，试图阻止这些都是徒劳的。我们仍然在组件中使用shadow DOM，但是样式封装方面并不是我们真正积极尝试利用的东西。我们将从中受益的任何元素移到light DOM中（同时出于不同的技术原因将其他部分保留在影子DOM中），并且我们已经准备好将任何元素公开为一个命名部件，对于该命名部件，定制CSS有一个明确的用例。
我在这里说的当然是关于一个非常通用的组件库，它不是为特定的产品或公司内部使用，而是为成千上万的公司以他们喜欢的任何方式使用，这通常包括调整外观和感觉，在某些情况下甚至布局/结构CSS，以满足他们的需要。
如果我要为一个为特定公司或产品量身定制的设计系统构建一组组件，我可能会更倾向于限制可定制性，但我仍然需要平衡可访问性等。
为了回答你的问题
1.如果坚持使用命名部分和根元素（和伪元素），你可能会很好，但这不是保证。按照发行说明，看看是否有突破性的变化，并阅读升级指南时，他们发布。（同时，我们将发布Vaadin 24官方支持的选择器列表--这将给予您更好地了解我们所认为的“公共样式API”，但不能保证在未来的版本中不会发生任何变化。）
1.如果它是为第三方设计的，那就不要尝试。让他们做什么都行。但是当一个新版本改变了一些可能会破坏第三方CSS的东西时，要清楚地沟通。（我们尝试通过我们为主要版本发布的升级指南来自己做这件事。）如果它是为一个内部产品/组织特定的库设计的，你需要决定什么（如果有的话）应该是可定制的。

例如：当API消费者改变css显示属性时，用根flex容器构建web组件将中断，因此在这种情况下，将flex容器移动到shadow DOM可以使组件不那么脆弱。
对于这种特定情况，一种选择是在阴影DOM样式中使用!important，这可以防止浅色DOM样式覆盖它们：

:host {
  display: flex !important;
}

另一个有用的工具是重置主机上的所有属性，这样就不会有来自轻量级DOM的任何意外（主要是继承的属性），然后使用!important设置组件正常工作所需的任何属性：

:host {
  all: initial;
  display: flex !important;
}