Re: [w3c/selection-api] Let addRange not update existing range (#80)

As a WebKit maintainer, while I do agree we need some API like a multi-range selection, I'm not convinced that the current multi-range API supported by Gecko is the right API.

For one, letting author specify arbitrarily overlapping, nested, or otherwise ill-constructed is troublesome for implementors and hard to use at times especially when boundary points get adjusted per DOM mutations.

Secondly, WebKit, Blink, and Edge never supported the multi-range selection, and there is a significant compatibility risk that the Web content in the wild does not properly support multi-range selection.

For these reasons and beyond, I don't think we're willing to adopt the multi-range selection in the form Gecko supports at least in near future. I do understand that for Gecko to drop multi-range selection support, or to change its behavior is a significant compatibility risk as well. But I'm not certain having that conversation right now is the best way to get the interoperable behavior in near term either.

Making the behavioral change proposed in this issue at least brings WebKit/Blink's behavior closer to Gecko's and matches that of Edge so that seems like a pretty good step forward towards interoperability in selection API.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/selection-api/issues/80#issuecomment-280220150