- From: Koji Ishii <kojiishi@gmail.com>
- Date: Sat, 24 Jan 2015 16:52:44 +0900
- To: Mats Palmgren <mats@mozilla.com>
- Cc: Aryeh Gregor <ayg@aryeh.name>, Ryosuke Niwa <rniwa@apple.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On Thu, Jan 22, 2015 at 12:20 AM, Mats Palmgren <mats@mozilla.com> wrote: > >> If we really want authors to have convenience methods like >> setStartBefore() on Selection, we could add them to Selection. > > 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. We could add, say, getRangeProxyAt(index) to get a selection object that has Rage interface if this is really what authors want. But right now, authors are not relying on the live-ness behavior because it's not interoperable. As I understand, "not-interoperable" is bigger issue than "getRangeAt(index) does not have live-ness". In selections and editing, we have so much we wish to do, I'd like us to solve bigger issues first, make them available to editor developers, then improve as needed. Actually -- well, only if you're interested in doing this -- you could have both methods, then see how much authors prefer the live-ness. If it's proved that the live-ness is so much liked by editor developers, and if we have solved other critical issues at that point, I do not see any reasons other browsers do not follow. /koji
Received on Saturday, 24 January 2015 07:53:16 UTC