- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Sat, 17 Jan 2015 19:11:02 +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>
I just said it in the other thread, but just to clarify in this thread too: I think non-contiguous selections are a great feature. I think exposing them to authors as multiple Ranges in a Selection has proven to be not a good way to do it, because authors basically without exception just ignore any ranges beyond the first. When writing the Selection code, I reviewed a decent amount of author code, and all of it (I don't think I found an exception) just did .getRangeAt(0) and ignored the rest. Gecko has found that they misused the code internally as well, as Ehsan demonstrated to me once. If we want non-contiguous selections to work in author code that's not specially written to accommodate them, we should think of a different API, perhaps the one I suggested in the other thread. Also, to clarify, my initial selection spec accommodated multiple ranges. I deliberately removed support when it looked like no one wanted to support the feature: <https://dvcs.w3.org/hg/editing/rev/b1598801692d>. Speccing it is not the problem. The bug was here, where I say that Ehsan and Ryosuke agreed with it (at a face-to-face meeting we had at Mozilla Toronto): <http://www.w3.org/Bugs/Public/show_bug.cgi?id=13975> On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren <mats@mozilla.com> wrote: > On 01/09/2015 12:40 PM, Aryeh Gregor wrote: >> >> The advantage of the IE/Gecko behavior is you can alter the selection >> using Range methods. The advantage of the WebKit/Blink behavior is >> you can restrict the ranges in the selection in some sane fashion, >> e.g., not letting them be in detached nodes. > > 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? What are the reasons to return a clone anyway? Is it important to be able to call (mutating) Range methods on a Selection? If we really want authors to have convenience methods like setStartBefore() on Selection, we could add them to Selection.
Received on Saturday, 17 January 2015 17:11:58 UTC