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

[whatwg] Normalization of user selections

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Tue, 28 Jun 2011 13:38:34 -0400
Message-ID: <BANLkTi=ZbR2-HvktBfh-1oHurCF9uV88sQ@mail.gmail.com>
On Fri, Jun 17, 2011 at 1:40 PM, Aryeh Gregor <AryehGregor at gmail.com> wrote:
> However, I'd still like to normalize author-set selections somewhat.
> At a minimum, for instance, we could guarantee that a selection's
> boundary point is always in a Text or Element node that descends from
> a Document. ?That would be a big simplification by itself. ?Does
> anyone object to that?

I've updated the spec to require this:


The boundary points of a selection's range must now always be a Text
or Element node that descends from a Document.  Trying to call
collapse(), extend(), selectAllChildren(), or addRange() in a way that
would make a boundary point not a Text or Element node will throw
INVALID_NODE_TYPE_ERR, and trying to make it a node that doesn't
descend from a Document will throw INVALID_MODIFICATION_ERR.  I'll add
more specific constraints on user-created selections later.  Does
anyone think this is a bad approach?  If so, feedback would be

One problem arose when I was doing this: what happens if the user gets
a range with getRangeAt() and then alters it directly?  In WebKit and
Opera, getRangeAt() returns a copy, so this is no problem, but in IE
and Gecko (and per current spec) it returns a reference.  The simplest
solution would just be to change the spec to match WebKit and Opera
here, so getRangeAt() returns a copy of the range and addRange() adds
a copy of the range.  The only downside I can see is it's more
complicated to alter a multi-range selection -- you'd have to remove
and re-add a range to change it.  But this doesn't seem like a big
deal.  Any objections if I change the spec to make these methods do
Received on Tuesday, 28 June 2011 10:38:34 UTC

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