- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 28 Jun 2011 13:38:34 -0400
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: https://bitbucket.org/ms2ger/dom-range/changeset/b9ca1640aeee http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface 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 appreciated. 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 copies?
Received on Tuesday, 28 June 2011 10:38:34 UTC