Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)
On Sat, Jan 24, 2015 at 9:35 AM, Aryeh Gregor a...@aryeh.name wrote: It's not just that it was only implemented by one UA. It's also that even in Firefox, multiple-range selections practically never occur. The only way for a user to create them to to either Ctrl-select multiple things, which practically nobody knows you can do; or select a table column, which is also extremely uncommon; or maybe some other obscure ways. In evidence of this fact, Gecko code doesn't handle them properly either. Ehsan might be able to provide more details on this if you're interested. 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. ~TJ
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] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)
On Sat, Jan 17, 2015 at 10:12 PM, Olivier Forget teleclim...@gmail.com wrote: I'd be interested in hearing more about what didn't work with that API by both devs who tried to make use of it and the implementors too. For the record: web developers don't usually take advantage of additional functionality that is provided by only one browser, or implemented in differing unpolished ways by different browsers. When possible we take the lowest common denominator approach to offer a consistent experience from browser to browser, and to avoid spending resources writing code that only a subset of users will be able to use anyways. What I'm saying is that the fact few devs worked with multiple ranges may not be a reflection of the quality of the API, but rather that because it wasn't implemented across browsers it wasn't worth from a cost-benefit point of view. And no I'm not saying the API is great either, just that saying developers won't do it is not really fair to anybody. It's not just that it was only implemented by one UA. It's also that even in Firefox, multiple-range selections practically never occur. The only way for a user to create them to to either Ctrl-select multiple things, which practically nobody knows you can do; or select a table column, which is also extremely uncommon; or maybe some other obscure ways. In evidence of this fact, Gecko code doesn't handle them properly either. Ehsan might be able to provide more details on this if you're interested.
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
