On Wed, Feb 10, 2016 at 5:15 AM, Ojan Vafai <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? > > On Tue, Jan 12, 2016 at 5:33 AM Enrica Casucci <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> 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
Received on Wednesday, 10 February 2016 12:10:12 UTC