W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2011

[whatwg] Selection events in editable content

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Tue, 10 May 2011 10:49:23 -0700
Message-ID: <BANLkTimY1+3G594Yytf-QpCWcGsjJSmX5w@mail.gmail.com>
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.
>
Received on Tuesday, 10 May 2011 10:49:23 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:33 UTC