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
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
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
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
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
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
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,
