Let addRange not update existing range

[yoichio]

If we have no range, addRange set new range to Selection, of course. What if we have a range in Selection? Chrome 58/Safari creates another range if exisiting range crosses newrange and ignore otherwise. Edge 25 ignores anyway. Firefox 51 appends the range and Selection.getRangeAt(1) returns the range. In the spec, new range replaces existing range.

For interoperability, I suggest updating spec in the case where Selection has a range and addRange: "If rangeCount is 1, addRange() should not update the range returned by getRangeAt(0)" This looks Edge 25 implementation but Firefox follow at least getRangeAt(0).

This spec assures:

s = getSelection();
r1 = new Range();
s.addRange(r1);
r2 = new Range();
s.addRange(r2);
assert(r1 == s.getRangeAt(0));

Put multi-range specifying later, how about unify addRange/getRange(0) behavior (this suggestion can be extended to multi-range)?

[rniwa]

If Blink can change the behavior, we can probably change the spec. Otherwise, there is no interoperability between browser engines so I have no motivation to change the spec unless you're willing to make the change in your engine first.

[tkent-google]

Yes, we want to change the behavior in Blink as yoichio wrote.

We'd like to improve Selection API conformance. But we have a concern that the current behavior of addRange() in the draft doesn't match to any implementations, and it won't improve interoperability.

[rniwa]

You can go ahead & change Blink's behavior to match Edge's behavior. Once such a change is merged into Blink, I'll change the spec.

[tkent-google]

All right. @rniwa , do you think WebKit wants the Edge behavior if Blink adopts it?

[rniwa]

As a WebKit maintainer, I don't have a strong opinion about this. It's a compatibility risk for WebKit to change the behavior so I mildly dislike the change but I'm not opposed to it.

[smaug----]

Couldn't we finally get the spec properly support multiple ranges, since that is what we will need eventually.

[yoichio]

I wrote rough pull-request for this: https://github.com/w3c/selection-api/pull/81 (I don't know process and how to submit to the spec with github. Please let me know)

This speck change doesn't prohibit to the way to multiple ranges, I think.

[rniwa]

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.

[yoichio]

@tkent-google changed the Chrome behavior following Edge: https://chromium.googlesource.com/chromium/src/+/552ceb6deed19e86f89eb32b8fb3923217cefd7e

Can we go forward?

[rniwa]

Sure, sounds good to me.