- From: Ryosuke Niwa <notifications@github.com>
- Date: Wed, 13 Oct 2021 17:44:29 -0700
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/79/942833219@github.com>
> > What is a concrete use case for doing this? > > I guess the most basic one: click a button that highlights whatever the user has selected with some color. To do that, you'd need to provide all shadow roots on the page, otherwise you'll get it wrong. I.e. if a user has selected half-way through some text inside a shadow root, you'll change the color for the entire shadow root contents, unless you pre-provide that shadow root in the call to `getComposedRange()`. That does directly against the basic feature of Shadow DOM: encapsulation. The whole point of having a Shadow DOM is to encapsulate the implementation details of a component from the rest of a web page. The idea that some scripts may need to apply new behaviors across components without those components opt'ing in goes against this basic principle. > What's a concrete use case that would be "confused" by receiving `Node`s that live in any (open) shadow root? Consider an editor component, which consists of a content editable region and a toolbar for things like bolding & italicizing text. As the user moves selection to different parts of the content editable region, the toolbar status may need to be updated. The component wants to do that by observing selection changes within the component. The proposed API which returns a node anywhere in the document will mean that this component will then have to check whether the selection resides within the content editable element of this component's shadow tree or not. This will be worse developer ergonomics than the proprietary API Blink has on ShadowRoot interface right now. > > The issue isn't so much about leaks in the case of open shadow roots but more about ergonomics & separations of concerns. If the only way to get the range of selection when its end points are in a shadow root is to get selection end points in any shadow root, then you're effectively back to not having shadow root encapsulation at all. You'd have to constantly check against end points to see if it's in your shadow root or not. > > I suppose the counterpoint is that for pages that want to make extensive use of shadow dom, this API shape gets really cumbersome. E.g.: > > ``` > <body> > <my-app></my-app> > </body> > ``` > > In this case, assuming `<my-app>` uses shadow DOM, `getComposedSelection(allRoots)` just doesn't work at all unless you pre-walk the tree and provide everything in `allRoots`. It's unclear that `getComposedSelection(allRoots)` is something we want allow anyone to be using. Again, this goes directly against the basic idea of encapsulation. > I'm curious why you think shadow dom is special here. The user is **already able** to select anything on the page, including inside deeply nested shadow DOM. The existing `getRangeAt()` already returns **any `Node`** on the page, not just inside some sub-tree. This new API is meant to extend that current behavior to `Node`s inside shadow trees. If you're writing some code that doesn't understand Shadow DOM, great, just keep using `getRangeAt()`. Because the whole point of Shadow DOM is to encapsulate its contents. If there is a desire for some scripts to access anywhere in the document, then why use Shadow DOM at all? Shadow DOM isn't designed to be general purpose API that can be used for any purpose whatsoever; its primary function is to *provide encapsulation*. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/79#issuecomment-942833219
Received on Thursday, 14 October 2021 00:44:42 UTC