Re: [Editing] Replacing `targetRanges` on `InputEvent` by `getTargetRanges`

I do have a question on getTargetRanges always returning non-null values.


I recall from our previous conversations that we wanted to fire beforeInput for text area and input with TargetRanges returning null in those cases. How will this work now?


--grisha


Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Ojan Vafai <ojan@google.com>
Sent: Wednesday, February 10, 2016 1:41:13 PM
To: Johannes Wilm
Cc: Enrica Casucci; Grisha Lyukshin; Ryosuke Niwa; public-editing-tf
Subject: Re: [Editing] Replacing `targetRanges` on `InputEvent` by `getTargetRanges`



On Wed, Feb 10, 2016, 11:09 PM Johannes Wilm <johannes@fiduswriter.org<mailto:johannes@fiduswriter.org>> wrote:
On Wed, Feb 10, 2016 at 5:15 AM, Ojan Vafai <ojan@google.com<mailto:ojan@google.com>> wrote:
Sorry for the delayed response...

I think we should not make targetRanges null. We should make it always populated so that people use that instead of the selection. The upside there is that their code will naturally work well in the context of IMEs where using the browser selection won't.

We have switched back and forth between the "keep it null if the same as the selection" and "always fill it" a few times since last spring. For jS editors, I think it would be the easiest if it was consistently on, so that one wouldn't have to additionally also check the selection. On the other hand, doing so would not be a big deal either.

Is anyone strongly opposed to having getTargetRanges always return something else than null, even if it is the same as the selection?

And Ojan, you are OK with switching from targetRanges to getTargetRanges, right?

Right



On Tue, Jan 12, 2016 at 5:33 AM Enrica Casucci <enrica@apple.com<mailto:enrica@apple.com>> wrote:
If it is used very seldom, one more reason to remove the parameter and just provide the method.

        Enrica


> On Jan 9, 2016, at 3:50 PM, Ryosuke Niwa <rniwa@apple.com<mailto:rniwa@apple.com>> wrote:
>
> Hi all,
>
> We discussed about replacing `targetRanges` on `InputEvent` by `getTargetRanges` because an event listener of `beforeinput` event can mutate DOM and a subsequent event listener can receive a bad range.  There was another concern about the cost of computing the range upfront at the event dispatching time.
>
> However, it looks like `targetRanges` is almost always NULL except when `replaceContent` is used for spelling correction, etc... so perhaps we don't need to make this change.
>
> Do you remember any other reason why we needed a method instead?
>
> - R. Niwa
>




--
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org<http://www.fiduswriter.org/>