Re: [Selection] Should selection.getRangeAt return a clone or a reference?
So...we discussed 31 e-mails, time to try to reach a consensus? Please keep in mind, it's too obvious to everyone but you don't have to agree to build a consensus. We can build a consensus if all can live with single conclusion. 3 proposals so far: Proposal A: Leave it undefined. If it's not causing interop issues, we can leave it. Proposal B: Clone. Proposal C: Live. Which one you *can't* live with, and which one do you prefer? I can live with any, but prefer A or B. If anyone has more to say, I didn't intend to interrupt, please add more info. /koji On Sun, Jan 25, 2015 at 9:02 PM, Aryeh Gregor a...@aryeh.name wrote: On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren m...@mozilla.com wrote: Gecko knows if a Range is part of a Selection or not. Authors don't, I don't think. Of course, we could expose this info to authors if we wanted, so that's not a big problem. 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. I don't think there are any implementation problems, I just think it's an API that's confusing to authors relative to the alternative (returning copies). And it's probably easier for the UAs that return references to switch to returning copies than the reverse, so it increases the chance of convergence in the near term. Also, if mutating the range throws, it will break author code; but if it fails silently, it creates a what on earth is going wrong?! head-banging scenario for authors. And anything authors can do with a reference, they can do with a copy just as well, by mutating the copy, .removeRange(), .addRange(). So I think returning a copy makes much more sense.
Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)
I thought a bit of the same thing as Tab when I saw the visual focus discussion in CSS WG, but my current conclusion is not to think the two the same thing. Focus may be possible, but selections is a different thing. It's true that you could use multi-range selections to select in visual order. But there are bunch of operations defined against selections. What does it copy? What will happen when you type a to replace the selected text? Spell check? Bi-di algorithm? Almost every text algorithm is built on top of the model, which is the DOM today, we can't just replace it. I actually like multi-selections. Visual Studio allows me to select multiple ranges, and when I type, it changes all of them at once, just like the replace-all command. That's really a nice feature. But as you can see in this example, operations would behave differently against multi-selections. I think visual order selections, if ever happens, should have a different architecture, and it should not be handled together with multi-range selections. /koji On Sun, Jan 25, 2015 at 8:57 PM, Aryeh Gregor a...@aryeh.name wrote: On Sat, Jan 24, 2015 at 9:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Though I believe browsers will soon have much more pressure to support multiple ranges as a matter of course, as increased design with Flexbox and Grid will mean that highlighting from one point to another, in the world of a range is defined by two DOM endpoints and contains everything between them in DOM order, can mean highlighting random additional parts of the page that are completely unexpected. Switching to a model of visual highlighting for selections will require multi-range support. In other words, it'll switch from being a rare thing to much more common. Most sites will probably not use flexbox or grid for a long time to come, and on sites that do non-contiguous selections will probably be rare, so I wouldn't rely on this as a mitigating factor. I once went through some common selection use-cases with the new selection API that I suggested before (returning a list of selected nodes or such), and for at least some common cases (like wrap the selection in a span) it handled non-contiguous selections automatically, and was easier to use as well. For typical selection use-cases, the author wants to deal with the selected nodes anyway, not the endpoints.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Sat, Jan 24, 2015 at 9:52 PM, Olli Pettay o...@pettay.fi wrote: Right now the liveness doesn't really cause issues, since only some UAs support it. But that doesn't mean getRangeAt should return cloned ranges. Adding another getRange*At would just pollute the API. The more I think this, the more I'm leaning over to the option that we should play with live range objects with selection. (but perhaps there is some different kind of API model which can support multiple ranges and getRangeAt could be left as a legacy method and return clones. But adding something like getRangeProxyAt would not be such new model.) The more you think of a nice feature, the nicer it looks to you. I don't disagree with you. Looks like we're in consensus that a) it doesn't really cause issues today, and b) there are scenarios where live-ness is nice. The difference is only that you think we should put in such thing now, while I see such features can be added later and I'd like to spend our time on other things. If the current situation is not causing any practical issues, I'm even fine not to define it in this level. Interoperability is important and I like that, but if one particular difference does not trouble web authors/developers at all, it can be left undefined, and we can re-visit in Selection API Level 2. In selections and editing, we have so much we wish to do, I'd like us to solve bigger issues first, Like what? The Editing TF needs 4 more specs to be written, and the WG lacks editor resources. As we discuss editing, there are some additional requests to Selection APIs. These are that really cause issues today. How we end up supporting multiple ranges is rather big thing and something to keep in mind even if we end up having some kind of v1 spec without support for it. Agreed. That's another concern actually. Making it live, with multiple ranges kept in mind, would need more edits and thus need some time from Ryosuke, the editor. I need his time spend more on contentEditable=typing. /koji
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Thu, Jan 22, 2015 at 12:20 AM, Mats Palmgren m...@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
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
As in the thread Ben split, I think it's just Aryeh omitted in the current spec focus. Visual Studio supported multiple selections in version 11 or so. MS Word, I don't remember, but probably version 9 or 10. I agree that it's a great feature, but also agree with Aryeh and Ben that we have a lot to do before that. Can we discuss this in the other thread if any and get back to the original topic of whether we're ok with returning a clone or not? /koji On Tue, Jan 13, 2015 at 8:54 PM, cha...@yandex-team.ru wrote: 13.01.2015, 05:31, Boris Zbarsky bzbar...@mit.edu: On 1/12/15 1:56 PM, Olivier Forget wrote: Unfortunately multiple range selections are not a nice to have. All real editors (MS Word, Google Docs, etc..) support selecting multiple ranges Precisely. This is why Gecko ended up supporting it: it was needed for the editor that was part of the Mozilla suite back in the day Of course I've made this point before; it just got ignored. :( :( And yeah, painful as it may be to implement in the browser, I suspect in the long run it is the right answer. cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
Thank you Aryeh for the explanation to this newbie, I understand that better now. That was a bit different from what I had in mind, but glad to see you agree to return a value. So, sounds like we're in consensus to change it to return a value? /koji On Fri, Jan 9, 2015 at 9:40 PM, Aryeh Gregor a...@aryeh.name wrote: On Wed, Jan 7, 2015 at 12:32 AM, Ryosuke Niwa rn...@apple.com wrote: Trident (since IE10) and Gecko both return a live Range, which can be modified to update selection. WebKit and Blink both return a clone Range so that any changes to the Range doesn't update the selection. It appears that there is a moderate interest at Mozilla to change Gecko's behavior. Does anyone have a strong opinion about this? 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. WebKit/Blink cannot change to return a reference unless they allow arbitrary ranges in selections, which last I checked they don't, and I'm guessing they would have trouble supporting it. Whereas IE/Gecko could easily change, and authors who already supported WebKit/Blink wouldn't lose any features. So I guess returning a value makes the most sense. (If you return a reference, you must allow arbitrary ranges, because the author could call setStart() on the returned range with any value you want, and they will expect that the range's new start will be exactly what they set it to.) On Wed, Jan 7, 2015 at 12:08 PM, Koji Ishii kojii...@gmail.com wrote: I also guess that we need to ask more work to the spec editor to support the liveness, such as: My old spec had no trouble answering these questions. I don't think it's particularly complicated, except it requires allowing arbitrary ranges to be in selections, and I suspect WebKit/Blink would have trouble dealing with that. - What will happen to the live-object on removeAllRanges()? The range is detached from the selection, so further changes have no effect. - Would the live-object keeps the same reference for removeAllRanges() + addRanges()? No. If you use addRange(), a reference to your existing range is put in the selection. - It may never happen, but when multiple ranges are supported, are they bound to index? Everyone wants to kill this feature, so it's moot. Specing them in detail and writing tests for all these cases would be quite a bit of work. I already wrote the spec and the tests, although I'm sure there are still some gaps. I think WebKit/Blink are the bigger obstacle.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
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 feel sorry for already implemented people though. I also guess that we need to ask more work to the spec editor to support the liveness, such as: - What will happen to the live-object on removeAllRanges()? - Would the live-object keeps the same reference for removeAllRanges() + addRanges()? - It may never happen, but when multiple ranges are supported, are they bound to index? Specing them in detail and writing tests for all these cases would be quite a bit of work. /koji On Wed, Jan 7, 2015 at 9:02 AM, Tim Down t...@timdown.co.uk wrote: For what it's worth as a user of the range and selection APIs, updating a live range is convenient and preferable, but since this has never worked in all browsers, I never do it and have never recommended it to anyone else. Therefore if Gecko changes, nothing really changes for me, so I don't care. Knock yourself out, Mozilla. Tim On 6 January 2015 at 22:32, Ryosuke Niwa rn...@apple.com wrote: https://github.com/w3c/selection-api/issues/40 Trident (since IE10) and Gecko both return a live Range, which can be modified to update selection. WebKit and Blink both return a clone Range so that any changes to the Range doesn't update the selection. It appears that there is a moderate interest at Mozilla to change Gecko's behavior. Does anyone have a strong opinion about this? - R. Niwa
