[whatwg] Selection events in editable content

On Thu, Jun 2, 2011 at 7:27 PM, Ojan Vafai <ojan at chromium.org> wrote:
> TL;DR version: Having Selections update as the DOM is modified seems to me
> like considerable added complexity without a good use-case.

If it's a Selection object, it will have an associated Range object,
and all Range objects update as the DOM is modified anyway.  How is it
any different from if the user creates a Range object and stores it
someplace as a global?  That will update as the DOM is modified too.
Updating it will be O(N) in the number of such objects floating
around, but authors can already create an array of a thousand Ranges
if they feel like it, and those all have to be updated too.

As far as use-cases, if the range isn't updated, it might wind up
pointing to someplace that has no relationship to the original
selection.  For instance, the node it points to might have been
removed from the document, and then the author will have no way to
tell where it originally was.  Or children might have been added or
removed, or replaceData() or something called on a text node, so that
the offsets are wrong (or even beyond the end of the node).

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

How can they do that?  As long as the boundary points it's pointing at
are still in the document and the offset isn't greater than the node's
length, the author has no way to tell if they're meaningfully the same
boundary points as when the event occurred.  E.g., if there's some
Text node and the users selects "foo[bar]baz", but then before the
script handles the event the user cancels that selection and modifies
the Text node to "quuzfoobarbaz", if the offsets weren't updated, the
old Selection object will look like "quu[zfo]obarbaz", which has
nothing to do with what the user ever selected.

Received on Friday, 3 June 2011 09:35:58 UTC