One implication of adding newSelection property is that this selection may behave differently against DOM mutations at least in WebKit's implementation.
Should newSelection be updated upon DOM mutations by scripts and user actions in the same way frame's selection will be updated? On one hand, this will ensure that base and extent nodes offsets are resilient against DOM mutations but will degrade the performance with O(n) where n is the number of newSelection objects on the other hand. Any opinions? - Ryosuke On Tue, May 10, 2011 at 9:57 AM, Ojan Vafai <[email protected]> wrote: > On Tue, May 10, 2011 at 9:51 AM, Ryosuke Niwa <[email protected]> wrote: > >> On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai <[email protected]> wrote: >> >>> On Tue, May 10, 2011 at 8:55 AM, Tim Down <[email protected]> wrote: >>> >>>> newSelectionRanges on its own wouldn't be as useful as possible, since >>>> it tells you nothing about the selection direction. You could cover >>>> this by adding newSelectionFocusNode, newSelectionFocusOffset, >>>> newSelectionAnchorNode and newSelectionAnchorOffset as well. >>>> >>> >>> Could we just put a Selection object on the event? That way, if we add >>> new fields to Selections, we won't need to add new fields to the selectstart >>> event. >>> >> >> Should we support methods such as modify, collapse, setPosition? >> > > Yes. >
