Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/24/2015 05:50 PM, Aryeh Gregor wrote: On Wed, Jan 21, 2015 at 5:20 PM, Mats Palmgren m...@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? Gecko knows if a Range is part of a Selection or not. It's pretty much a one-line change to reject detached nodes if we want. 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. True, I'm just saying that I don't see any practical problems in implementing live ranges to manipulate the Selection if we want to. /Mats
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/17/2015 05:11 PM, Aryeh Gregor wrote: On Wed, Jan 14, 2015 at 6:14 PM, Mats Palmgren m...@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
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
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? /Mats
Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)
On 01/12/2015 07:59 PM, Ben Peters wrote: Multiple selection is an important feature in the future. Indeed, there are many important use cases for it. Here are some use cases that are implemented using multi-range selections in Gecko today: * visual selection of bidirectional text * selecting table columns * selecting multiple fragments of arbitrary content (just hold CTRL) * selection with disjoint unselected islands due to CSS user-select:none * mapping spell-checking errors * highlighting matched words for Find in Page etc I do not believe “everyone wants to kill it” is accurate. I agree with Olivier that it’s crucial to a full-featured editor. We don’t want to make sites implement this themselves. Strongly agreed. This is complicated to implement correctly and can be very slow if you're not careful. It should be implemented in the UA. Since Ranges are well specified, including how they stay valid under DOM mutations (DOM spec), I don't see why we should re-invent the wheel here. Especially since there is no alternative proposal on the table. BTW, this topic was discussed a while ago on this list: http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0620.html http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0627.html /Mats
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/07/2015 10:08 AM, Koji Ishii wrote: While I agree that it's nice, I have mild preference to return a clone. As Olii said, changing from clone to live would involve quite a bit of code. I don't think he said that. He said implementing the live-ness properly can be somewhat annoying, which I think refers to implementing updates on Ranges in general. As I wrote much of this code in Gecko I agree with what he is saying: 1. updating Ranges in response to DOM mutations is somewhat complex, 2. updating the selection though is simple - if you implement it as a set of Ranges you get it for free I don't think supporting live Ranges here is hard or would involve quite a bit of code (1 does, but not 2). But UAs must implement 1. for arbitrary Ranges anyway (per the DOM spec). /Mats
