- From: Mats Palmgren <mats@mozilla.com>
- Date: Wed, 21 Jan 2015 15:20:09 +0000
- To: Aryeh Gregor <ayg@aryeh.name>
- CC: Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>
On 01/17/2015 05:11 PM, Aryeh Gregor wrote: > On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren <mats@mozilla.com> > wrote: >> It would be easy to change Gecko to ignore addRange() calls if the >> range start/end node is detached. We could easily do the same for >> range.setStart*/setEnd* for ranges that are in the Selection. Would >> that address your concern about detached nodes? > > I think so, yes, but it would mean making Range methods behave > differently depending on whether the range is in a selection. Is that > really sane? 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. (*) It appears to collapse the current range, if any, at the end point, but I might be mistaken on the exact behavior. I would prefer to simply ignore calls with detached nodes and leave the Selection as is, but I don't feel strongly about it. > 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. /Mats
Received on Wednesday, 21 January 2015 15:20:40 UTC