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

Thanks for the review and the question. (And sorry for the delay replying!)

So I think the main reason for the new function, vs. re-using the old `getRangeAt()`, is backwards compatibility. This is mentioned a few places in the explainer, but the thought is that we would likely break sites if we just change `getRangeAt()` to return a `StaticRange` (rather than a *live* `Range`) that also crosses shadow bounds. Perhaps you were implying that if the developer passed a `ComposedRangeOptions` to `getRangeAt()`, you'd get the new behavior? The problem there is that the `ComposedRangeOptions` is optional, so a call like `getRangeAt()` (with no arguments) would now get the new behavior. That's likely ok compat-wise, since the existing behavior is to throw an exception with no arguments. However, in all current rendering engines, `getSelection().getRangeAt({})` currently returns the live `Range`. So there's the possibility of compat problems if existing sites are using `getRangeAt({})` for whatever reason.

Overall, I think the motivation for a new API was that we're rather-significantly changing the selection API, and beyond the calling syntax, developers will have to understand more about shadow DOM and how this new API works. Giving it a fresh/different function name helps (in my opinion) them understand that there's a difference.

I'm open to suggestions, of course.

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

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