- From: Justin Fagnani <notifications@github.com>
- Date: Fri, 16 Sep 2022 21:03:15 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/909/1249993052@github.com>
> If you don't want encapsulation, don't use shadow-DOM. It was designed for encapsulation. Not to single you out, because I've head this response from a few people so far, but I think this is a misguided and exclusionary sentiment on both technical grounds and ecosystem considerations. On a technical level, we know that relaxing encapsulation up to selectively breaking it is useful and _necessary_ in many ways, and we have _many_ examples of it, both default behavior and opt-in: - CSS properties inheriting through shadow boundaries - Composed events let elements in a shadow root fire events that seem to come from their hosts - `event.composedPath()` - Custom element tag names in a shadow root use the global registry - `::slotted()` lets a shadow root style elements outside of it - CSS shadow parts let an outer scope style elements Without these holes in encapsulation the encapsulation would be too strict to be usable. So we already don't have fully strict encapsulation, and the hard-line statement "If you don't want encapsulation, don't use shadow-DOM. It was designed for encapsulation." already doesn't match reality. We also know that shadow DOM includes a _lot_ more than just style scoping (and lower-bound scoping, which this idea is focused on). If you ditch shadow DOM because you need component internals to be styled, then you also lose interoperable composition (slots), upper-bound style-scoping, event retargeting, DOM encapsulation, and soon things like scoped custom element registries. On an ecosystem level, we hear over, and over, and over again from current users and would-be users (and detractors) of web components that the style scope upper-bound is a huge impediment to adoption. Many developers have said to my team that they want to use web components, but need to incrementally place them into contexts where there are global stylesheets in place that style component internals. Since they can't do this with shadow DOM, and without shadow DOM it's very difficult and awkward at best to have children provided by component users, I've seen them just skip web components and build, say, React components and try to get their other framework users and even plain HTML users to adopt React. This is turning away people who could otherwise use everything else good about web components except shadow DOM lower-bounds on specific components! These users could potentially even re-enable lower-bound scoping in the future once we figure out something like ::theme() and their client stylesheets are updated - maybe on a component-by-component basis. Maybe it takes years, but it's possible and they get to incrementally adopt more encapsulation as they go. I strongly believe, from many years of having the same conversations over and over, that this is one of the largest blockers to web components adoption (along with scoped custom element registries and declarative shadow DOM) and that the standards should do a better job of meeting developers where they are and letting them incrementally adopt the features that web components provide. It's far better than them getting nothing. It's important to remember too that this feature would be opt-in: it would be a choice by component developers to relax the style scope lower-bound, and I trust that they would make that choice as an informed decision. We should be careful of being patronizing to repeated informed feedback from developers by saying that they don't really want or need what they're clearly asking for. -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/909#issuecomment-1249993052 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/909/1249993052@github.com>
Received on Saturday, 17 September 2022 04:03:28 UTC