[whatwg] Selection events in editable content

[Ojan Vafai]

TL;DR version: Having Selections update as the DOM is modified seems to me
like considerable added complexity without a good use-case.

I strongly believe we should not do this. I don't like adding new things
that need to be updated every time a node is added/removed from the DOM. I
don't see any problem with the Selection objects getting stale. The author
can easily write code to verify that the Selection object is in a valid
state if they need to.

On Tue, May 10, 2011 at 10:49 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:

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