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

Hi @mfreed7,

We revisited this today during our Hybrid F2F. We understand the reasoning for defining a new function rather than overloading `getRangeAt()` and we agree that a new function is needed (having a function return different types depending on arguments is not a good idea).

One thing we noticed is that with the addition of this new function, we will now basically have two independent concepts: 
a. _"Does the range cross Shadow DOM boundaries?"_ and 
b. _"Do we need a live or a static range?"_

While these are orthogonal, authors cannot specify any of the 4 combinations independently, but only two ([a. no, b. live] or [a. yes, b. static]), which is a coupling that could be confusing since these are not intrinsically related. We understand why [a. yes b. live] is not desirable, but perhaps there is value in designing the API so that [a. no, b. static] can be specified as well, which would make the new function a more general replacement for `getRangeAt()` as long as live ranges are not desired. What do you think?

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

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