- From: Serhii Kulykov <notifications@github.com>
- Date: Sun, 16 Feb 2020 13:07:32 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/864/586752811@github.com>
> At extreme, you end up with all style rules present in every component. That sort of defeats the point of style isolation shadow DOM provides. While some people in other teams have concerns about not being able to easily share "normalize" etc between components, the only thing that we do need at Vaadin is an ability to style elements exposed with `part` (and `:state` when it gets cross-browser support). As an example, even though we allow injecting any CSS into shadow roots of our components, we have an agreement that is documented and should be followed by the teams that use them: > Do not rely on the element type which a part applies to. For example, given <input type="text" part="value">, you should not rely on the information that the element is actually a native <input> element. This is considered as an internal implementation detail, and the element type could change in the future In order to make the discussion more productive, let's focus on theming with shadow DOM isolation in mind. IMO, if a developer wants to "tell the component from the outside to let styles leak in", that is an anti-pattern, same as using `!important` or setting `style` on elements in shadow tree. > If we had a scoped custom element registry @rniwa that's a good point that I didn't consider previously but actually we have a use case. At Vaadin, we have two themes implementing different designs (our own, called Lumo and Material). Currently they are both implemented with our `ThemableMixin` approach. Because of that, we can't use them on the same page: component tag names are the same, so the styles would clash. Having a theming option that works with scoped registries would also help to implement "micro frontends" or "embedding", which is another topic that some of our users are interested in: - An app is built using "micro frontends" approach and maintained by different teams - Independent parts of the app might use different versions of the same web components - Web components might have major version bumps that affect public API (`part` / `:state`) - All the teams want to use consistent theming, but without having to depend on each other when it comes to deployment cycle (some might want to stay on older versions etc) - Scoped custom elements registries allow to actually use different major versions in the app It would be nice to come up with a theming option that would support scoped CE registries in a way that all the requirements listed above would be possible without using `<iframe>`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/864#issuecomment-586752811
Received on Sunday, 16 February 2020 21:07:44 UTC