[prev in list] [next in list] [prev in thread] [next in thread] 

List:       whatwg
Subject:    Re: [whatwg] Normalization of user selections
From:       Aryeh Gregor <ayg () aryeh ! name>
Date:       2011-10-24 17:48:44
Message-ID: CAKA+Ax=ZrD-mhqE=Z8UUObieYnWA2qnqM_bYvcg1xV4NAJVySQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jun 28, 2011 at 1:38 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wr=
ote:
> 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-selec=
tion:-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. =C2=A0Trying 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. =C2=A0I'll a=
dd
> more specific constraints on user-created selections later. =C2=A0Does
> anyone think this is a bad approach? =C2=A0If so, feedback would be
> appreciated.

I eventually reverted this change:

http://dvcs.w3.org/hg/editing/rev/f8c262d61ccc

The reasons are explained in the commit diff.  I couldn't get away
with saying "Selection endpoints can't be Comments" or such unless I
defined what to do to the Selection if one of its Ranges changed, such
as due to a DOM mutation.  That would be a lot more complicated than
just speccing the IE/Gecko behavior, it wouldn't match any browsers,
and it would add only dubious utility.  So now the spec matches
IE/Gecko again -- any Range can be passed to addRange(), and a
reference to that Range will be added to the Selection.
[prev in list] [next in list] [prev in thread] [next in thread]