Re: [whatwg/dom] Add FormControlRange interface (PR #1404)

dandclark left a comment (whatwg/dom#1404)

> Changing the behavior of setStart/setEnd wouldn't be an only way to solve this problem. I'd instead add a new argument or a new function which specifies "offset" within element's shadow tree.

@rniwa Thanks for the feedback! Yeah, there are a lot of ways this could be done. This suggestion sounds closer to the 2nd considered approach [here](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/FormControlRange/explainer.md#extending-the-range-api-2nd-approach). There are enough differences in how a Range inside a builtin element would work vs a "normal" range that we believe it will be overall cleaner and less confusing to split the functionality into a different type. For example the behavior we propose here is that a FormControlRange can't have one boundary point inside a `<textarea>`/`<input>` and another boundary point outside, which would be a clumsier invariant to express with the Range API surface. Adding this to Range would also add confusion about what things like [`Range.selectNodeContents`](https://developer.mozilla.org/en-US/docs/Web/API/Range/selectNodeContents) should do; should it move the range to select an `<input>`'s value string, or not? We could add a parameter to all the setter functions to switch the behavior, but again it seems cleaner to relegate the behavior to a different interface vs adding parameters to a bunch of Range functions.

Anyway, https://github.com/whatwg/html/issues/11478 is a better place to have this discussion -- more folks are following that issue vs this draft PR. @stephanieyzhang it might be helpful if you could update the PR description for this to point to that issue, as well as a direct link to the explainer.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1404#issuecomment-3353952451
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1404/c3353952451@github.com>