Re: [w3ctag/design-reviews] Modification of selection APIs to account for shadow dom (Issue #694)

> We were under the impression that you only need to provide `shadowRoots` for closed shadows. It may be a little tedious to have to loop over the elements and recursively get all their shadows to provide to `shadowRoots`.

Right, the proposal started with only needing to provide `closed` shadow roots (and with a parameter called something like `closedShadowRoots`). I felt the same way - it seems like a hassle to have to go enumerate all of the shadow roots. However, after some discussion (e.g. see this summary from TPAC https://github.com/WICG/webcomponents/issues/79#issuecomment-946897700, point <span>#</span>2), it became clear that not only were other implementers against just requiring `closed` shadow roots, but also that perhaps for the typical use cases for this API it wasn't such a big ask. In particular, editor component vendors (the <span>#</span>1 use case) seem to want to get selection information *within* their component only, and receiving endpoints outside that tree, particularly inside other unknown shadow roots, was counterproductive. For these use cases, we added the `selectionRoot` argument, which makes the typical case work without needing to specify `shadowRoots` at all. There may be other use cases that require selection information *anywhere* in the document, but these haven't come to light. When they do, we could think about expanding the API with something like `getComposedRange({includeAllOpenShadowRoots: true})` or something. And in the meantime, they can certainly enumerate the shadow roots themselves, today.

LMK if that answers your question.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/694#issuecomment-1082211834
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/694/1082211834@github.com>