如何构建或定制一个好的（Vaadin）Web组件，这样CSS就不会太具有侵入性

Question

作为https://github.com/vaadin/web-components/issues/5214的替代解决方案，我们现在在头像（-group）的影子 DOM 中设置了一些 css 部分的样式。

我想知道的是：

1. 我们可以/应该在 Vaadin 中（但一般而言）设置 CSS（部分）样式到什么程度而不破坏向后兼容性？

2. 构建良好 Web 组件的最佳实践是什么/在哪里，以便 API 消费者不会太快地破坏向后兼容性。

例如：当 API 使用者更改 css 显示属性时，使用根 Flex 容器构建 Web 组件将会中断，因此在这种情况下，将 Flex 容器移动到 Shadow DOM 可以使组件不那么脆弱。但是，消费者仍然可能会破坏很多东西......

这同样适用于 CSS 部分。

Answer 1

Vaadin 组件的产品负责人位于此处。您问的问题与我们多年来一直在问自己的问题完全相同：

\n

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

\n

ETC。

\n

在 Vaadin 10 中，我们最初的方法是在基于 Web Component 的组件首次发布时，在 Shadow DOM 中尽可能隐藏组件的内部结构，并仅定义具有部件名称（和根元素）的元素作为部件“公共样式 API”的。

\n

然而这种方法有很多缺点：

\n

\n
1. 即使样式仅限于命名部分和根，元素也不会彼此独立渲染 \xe2\x80\x93 应用于阴影父级的 CSS 会影响其命名部分子级（在某些情况下反之亦然！），所以它是远非针对非面向未来的自定义 CSS 的防弹保护
\n
2. 您仍然可以通过这些公开的元素以各种方式破坏组件（尽管您确实需要专门针对它们，因此它确实可以防止样式无意中应用到组件）
\n
3. 选择哪些元素应该被命名为部件是一个困难的平衡行为：太少，你会过多地限制自定义样式；太多了，shadow DOM 风格封装的全部意义就被破坏了
\n
4. 事实证明，Shadow DOM 确实损害了可访问性和许多不错的浏览器功能，例如表单自动完成和密码管理器，因此我们必须将一些元素从影子移动到插槽中，从而将它们完全暴露给自定义 CSS。
\n

\n

今天，我对此事的看法是，试图阻止这一切都是徒劳的。我们在组件中仍然有影子 DOM，但样式封装方面并不是我们真正尝试利用的。我们将任何元素移动到从中受益的 light DOM（同时出于不同的技术原因将其他部分保留在 Shadow DOM 中），并且我们准备将任何元素公开为命名部分，对于自定义 CSS 有明确的用例。

\n

当然，我在这里所说的是一个非常通用的组件库，它并不是供特定产品或公司内部使用，而是供数千家公司以他们喜欢的任何方式使用，其中通常包括调整外观和感觉，在某些情况下甚至布局/结构 CSS，以满足他们的需求。

\n

如果我要为特定公司或产品量身定制的设计系统构建一组组件，我可能会更倾向于限制可定制性，但我仍然需要在可访问性等方面进行平衡。

\n

因此，为了回答您的问题：

\n

\n
1. 如果您坚持使用命名部分和根元素（和伪元素），您可能会没事，但这并不能保证。按照发行说明查看是否有重大更改，并在发布后阅读升级指南。（此外，我们将发布 Vaadin 24 \xe2\x80\x93 官方支持的选择器列表，这将使您更好地了解我们所认为的“公共样式 API”，但这并不能保证这些将在未来版本中改变。）
\n
2. 如果它是供第三方使用的，那就不要尝试。就让他们为所欲为吧。但是，当新版本更改可能破坏第 3 方 CSS 的内容时，请清楚地沟通。（我们尝试使用我们为主要版本发布的升级指南自行完成此操作。）如果是针对内部产品/组织特定的库，您需要决定哪些内容（如果有的话）应该是可定制的。
\n

\n