Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Tue, Jan 27, 2015 at 4:49 PM, Koji Ishii kojii...@gmail.com wrote: 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. I can live with any, but prefer B.
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] Should selection.getRangeAt return a clone or a reference?
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] Should selection.getRangeAt return a clone or a reference?
On Sat, Jan 24, 2015 at 3:28 PM, Koji Ishii kojii...@gmail.com wrote: 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. I don't agree that it doesn't cause issues now. Unless we want Range methods to behave differently based on whether they're in a Selection, returning a live range means you can't restrict what nodes are in the selection, e.g., detached nodes. This has caused at least one bug in Gecko. It would be much easier for IE/Gecko to switch to returning copies than for WebKit/Blink to switch to returning live ranges. And this opens up the possibility of normalizing the selection in a way that makes writing code to handle selections significantly easier, e.g., limiting the types of nodes that the selection can be in. So I think it makes more sense to spec returning a copy. I don't have any opinion on how this should be prioritized relative to other editing work. I will note that it would be quite easy for Gecko to switch to returning a copy, so it doesn't have to take significant implementation work away from other projects.
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 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? 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. True. 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.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/24/2015 09:52 AM, Koji Ishii wrote: 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. 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.) In selections and editing, we have so much we wish to do, I'd like us to solve bigger issues first, Like what? 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. -Olli 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?
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?
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?
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 m...@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.
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] Should selection.getRangeAt return a clone or a reference?
On Jan 13, 2015, at 4:21 AM, Arthur Barstow art.bars...@gmail.com wrote: On 1/13/15 6:54 AM, 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. If the `plan of record` is to not explicitly address selecting multiple ranges in the first version of the spec, perhaps a new issue should be created (with an `enhancement` tag). (I didn't notice such an Issue in https://github.com/w3c/selection-api/issues?q=is%3Aopen+is%3Aissue and will gladly create one if folks confirm that is the consensus and expectation.) Indeed, someone who feel strongly about this feature (multi-range selection) should feel a new issue. - R. Niwa
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 1/13/15 6:54 AM, 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. If the `plan of record` is to not explicitly address selecting multiple ranges in the first version of the spec, perhaps a new issue should be created (with an `enhancement` tag). (I didn't notice such an Issue in https://github.com/w3c/selection-api/issues?q=is%3Aopen+is%3Aissue and will gladly create one if folks confirm that is the consensus and expectation.) -Thanks, ArtB
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?
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?
On Jan 13, 2015, at 10:06 AM, Ryosuke Niwa rn...@apple.com wrote: On Jan 13, 2015, at 4:21 AM, Arthur Barstow art.bars...@gmail.com wrote: On 1/13/15 6:54 AM, 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. If the `plan of record` is to not explicitly address selecting multiple ranges in the first version of the spec, perhaps a new issue should be created (with an `enhancement` tag). (I didn't notice such an Issue in https://github.com/w3c/selection-api/issues?q=is%3Aopen+is%3Aissue and will gladly create one if folks confirm that is the consensus and expectation.) Indeed, someone who feel strongly about this feature (multi-range selection) should feel a new issue. Filed https://github.com/w3c/selection-api/issues/41 https://github.com/w3c/selection-api/issues/41 to track this. - R. Niwa
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Mon, Jan 12, 2015 at 3:40 AM, Karl Dubost k...@la-grange.net wrote: I'm using multiple range selection very often. From every day to a couple of times a week. My main usage is when I use bookmarking services and I want to keep part of an article which are distant. Basically a text1 […] text2 […] text3 scenario. I select when reading, and when finish I can bookmark all my selections in once. Also when I want to remove some noise from a paragraph. It's a lot more practical than having to create individual bookmark for each part OR to have to select, bookmark and cut. As a user I find that essential and very practical (implementation details apart). I think the proposal for Gecko was to leave multiple-range selections functional, but not expose anything beyond the primary range to author JavaScript. So there would be no change for users, only to authors.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Sat Jan 10 2015 at 8:30:34 AM Aryeh Gregor a...@aryeh.name wrote: I don't remember whether it was ever discussed on the mailing list in depth. The gist is that no one has ever implemented it except Gecko, and I'm pretty sure no one else is interested in implementing it. The Selection interface was invented by Netscape to support multiple ranges to begin with, but all the other UAs that reverse-engineered it and/or implemented from the DOM Range specs deliberately made it support only one range (in incompatible UA-specific ways, naturally). Ehsan Akhgari, maintainer of the editor component for Gecko, is in favor of removing (user-visible) support for multiple selection ranges from Gecko, and last I heard no one objected in principle. So the consensus of implementers is to support only one range. As far as I know, the only reason Gecko still supports multiple ranges is because no one has gotten around to removing them. (Ehsan would know more about that.) OK I understand that. My concern here is that the general attitude is to ignore this problem and hope it somehow goes away. Unfortunately multiple range selections are not a nice to have. All real editors (MS Word, Google Docs, etc..) support selecting multiple ranges, and it's very common for users to select a column of a table. As the web platform makes great strides forward rich editing capabilities should also keep up. If today we decide that multiple ranges is out then we are doing two things: - promoting the Selection is only ever one continuous range fallacy to all web developers. - delaying the arrival a decent spec that actually handles multiple ranges (or disjoint ranges or whatever it takes to do real world selections.) I am worried this means it will be a very long time before the web platform supports developing editors with commonly accepted editing paradigms.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/10/2015 06:30 PM, Aryeh Gregor wrote: On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget teleclim...@gmail.com wrote: On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote: - 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. Could you please point me to the discussion where this conclusion was reached? I searched the mailing list but I only found a few ambivalent threads, none indicating that everyone wants to kill this. Thanks. I don't remember whether it was ever discussed on the mailing list in depth. The gist is that no one has ever implemented it except Gecko, and I'm pretty sure no one else is interested in implementing it. The Selection interface was invented by Netscape to support multiple ranges to begin with, but all the other UAs that reverse-engineered it and/or implemented from the DOM Range specs deliberately made it support only one range (in incompatible UA-specific ways, naturally). Ehsan Akhgari, maintainer of the editor component for Gecko, is in favor of removing (user-visible) support for multiple selection ranges from Gecko, and last I heard no one objected in principle. So the consensus of implementers is to support only one range. As far as I know, the only reason Gecko still supports multiple ranges is because no one has gotten around to removing them. (Ehsan would know more about that.) I doubt we're going to remove support for multiple ranges, at least not internally. If the standardized/stable web API will support only one range, then perhaps expose only whatever primary range there is, but internally we need the functionality. (and personally I think supporting multiple ranges is a good thing, and if there are issues in an implementation, that shouldn't lead to weaker spec which doesn't support them.) -Olli The reason for all this is that while it makes wonderful theoretical sense to support multiple ranges for a selection, and is necessary for extremely sensible features like allowing a user to select columns of a table, multi-range selections are nonexistent in practice. A selection that has multiple ranges in it is guaranteed to be mistreated by author code, because no one actually tests their code on multi-range selections. More than that, Gecko code -- which is much higher-quality than typical author code and much more likely to take multiple ranges into account -- has tons of bugs with multi-range selections and behaves nonsensically in all sorts of cases. So in practice, multi-range selections break everyone's code in the rare cases where they actually occur. In general, an API that has a special case that will almost never occur is guaranteed to be used in a way that will break the special case, and that's very poor API design. In theory, a redesigned selection API that allows for non-contiguous selections *without* making them a special case would be great. Perhaps a list of selected nodes/character ranges. But multiple ranges is not the way to do things.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
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. :( -Boris
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
Pulling out my user hat: Le 11 janv. 2015 à 01:30, Aryeh Gregor a...@aryeh.name a écrit : The reason for all this is that while it makes wonderful theoretical sense to support multiple ranges for a selection, and is necessary for extremely sensible features like allowing a user to select columns of a table, multi-range selections are nonexistent in practice. I'm using multiple range selection very often. From every day to a couple of times a week. My main usage is when I use bookmarking services and I want to keep part of an article which are distant. Basically a text1 […] text2 […] text3 scenario. I select when reading, and when finish I can bookmark all my selections in once. Also when I want to remove some noise from a paragraph. It's a lot more practical than having to create individual bookmark for each part OR to have to select, bookmark and cut. As a user I find that essential and very practical (implementation details apart). -- Karl Dubost http://www.la-grange.net/karl/
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget teleclim...@gmail.com wrote: On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote: - 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. Could you please point me to the discussion where this conclusion was reached? I searched the mailing list but I only found a few ambivalent threads, none indicating that everyone wants to kill this. Thanks. I don't remember whether it was ever discussed on the mailing list in depth. The gist is that no one has ever implemented it except Gecko, and I'm pretty sure no one else is interested in implementing it. The Selection interface was invented by Netscape to support multiple ranges to begin with, but all the other UAs that reverse-engineered it and/or implemented from the DOM Range specs deliberately made it support only one range (in incompatible UA-specific ways, naturally). Ehsan Akhgari, maintainer of the editor component for Gecko, is in favor of removing (user-visible) support for multiple selection ranges from Gecko, and last I heard no one objected in principle. So the consensus of implementers is to support only one range. As far as I know, the only reason Gecko still supports multiple ranges is because no one has gotten around to removing them. (Ehsan would know more about that.) The reason for all this is that while it makes wonderful theoretical sense to support multiple ranges for a selection, and is necessary for extremely sensible features like allowing a user to select columns of a table, multi-range selections are nonexistent in practice. A selection that has multiple ranges in it is guaranteed to be mistreated by author code, because no one actually tests their code on multi-range selections. More than that, Gecko code -- which is much higher-quality than typical author code and much more likely to take multiple ranges into account -- has tons of bugs with multi-range selections and behaves nonsensically in all sorts of cases. So in practice, multi-range selections break everyone's code in the rare cases where they actually occur. In general, an API that has a special case that will almost never occur is guaranteed to be used in a way that will break the special case, and that's very poor API design. In theory, a redesigned selection API that allows for non-contiguous selections *without* making them a special case would be great. Perhaps a list of selected nodes/character ranges. But multiple ranges is not the way to do things.
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
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?
On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor a...@aryeh.name wrote: - 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. Could you please point me to the discussion where this conclusion was reached? I searched the mailing list but I only found a few ambivalent threads, none indicating that everyone wants to kill this. Thanks.
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
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
[Selection] Should selection.getRangeAt return a clone or a reference?
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
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On Tue, Jan 6, 2015 at 5:44 PM, Olli Pettay o...@pettay.fi wrote: On 01/07/2015 12:32 AM, Ryosuke Niwa 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? I don't have a strong opinion on this, although live Range can be rather nice thing when one wants to change the selection. But implementing the live-ness properly can be somewhat annoying - except that engines need to internally track DOM mutation inside selection anyway, so maybe not so bad after all. Perhaps speccing the special cases (like when one makes Range to point to detached dom subtree) would be enough? But as I said, I don't have strong feelings about this. I would be open to changing Gecko's behavior here (assuming that it would be Web compatible.)
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
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
RE: [Selection] Should selection.getRangeAt return a clone or a reference?
I'm not sure if any sites depend on the Gecko/Trident behavior, but I imagine any such sites also work in Webkit/Blink. So I'm fine with changing this unless anyone knows of an important dependency. -Original Message- From: Ryosuke Niwa [mailto:rn...@apple.com] Sent: Tuesday, January 6, 2015 2:32 PM To: Webapps WG Subject: [Selection] Should selection.getRangeAt return a clone or a reference? 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
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
On 01/07/2015 12:32 AM, Ryosuke Niwa 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? I don't have a strong opinion on this, although live Range can be rather nice thing when one wants to change the selection. But implementing the live-ness properly can be somewhat annoying - except that engines need to internally track DOM mutation inside selection anyway, so maybe not so bad after all. Perhaps speccing the special cases (like when one makes Range to point to detached dom subtree) would be enough? But as I said, I don't have strong feelings about this. -Olli - R. Niwa
