- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Sat, 24 Jan 2015 19:50:54 +0200
- To: Mats Palmgren <mats@mozilla.com>
- Cc: Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren <mats@mozilla.com> wrote: > It seems fine to me. WebKit/Blink already rejects(*) a range with > detached nodes in the addRange call. Imposing the same restriction on > a (live) Selection range is consistent with that. I don't think it's consistent at all. In one case, you're calling a Selection method. In the other case, you're calling a Range method. Range methods shouldn't behave differently based on whether the Range is attached to a Selection. You actually have no way of telling whether a given Range is part of a Selection, right? > Selection methods wouldn't provide the same functionality though. > Selection.setStart* would presumably be equivalent to setStart* > on the first range in the Selection, but how do you modify the start > boundary point on other ranges when there are more than one? > > I guess we could add them as convenience methods, making setStart* > operate on the first range and setEnd* on the last, but it's still > an incomplete API for multi-range Selections. True. You can still use the Range methods, you just have to do .removeRange() and .addRange() to update it. So it's not a significant issue, I think.
Received on Saturday, 24 January 2015 17:51:48 UTC