[whatwg] Selection events in editable content
ojan at chromium.org
Thu Jun 2 16:27:20 PDT 2011
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
> 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
> >>> event.
> >> Should we support methods such as modify, collapse, setPosition?
> > Yes.
More information about the whatwg