[whatwg] Selection events in editable content

[Ryosuke Niwa]

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 <ojan at chromium.org> wrote:

> On Tue, May 10, 2011 at 9:51 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
>> On Tue, May 10, 2011 at 9:03 AM, Ojan Vafai <ojan at chromium.org> wrote:
>>
>>> On Tue, May 10, 2011 at 8:55 AM, Tim Down <timdown at gmail.com> 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.
>