Re: [Selection] Should selection.getRangeAt return a clone or a reference?

On 01/10/2015 06:30 PM, Aryeh Gregor wrote:
> On Fri, Jan 9, 2015 at 8:29 PM, Olivier Forget <teleclimber@gmail.com> wrote:
>> On Fri Jan 09 2015 at 4:43:49 AM Aryeh Gregor <ayg@aryeh.name> wrote:
>>>
>>>
>>>> - It may never happen, but when multiple ranges are supported, are
>>>> they bound to index?
>>>
>>> Everyone wants to kill this feature, so it's moot.
>>
>>
>> Could you please point me to the discussion where this conclusion was
>> reached? I searched the mailing list but I only found a few ambivalent
>> threads, none indicating that "everyone" wants to kill this. Thanks.
>
> I don't remember whether it was ever discussed on the mailing list in
> depth.  The gist is that no one has ever implemented it except Gecko,
> and I'm pretty sure no one else is interested in implementing it.  The
> Selection interface was invented by Netscape to support multiple
> ranges to begin with, but all the other UAs that reverse-engineered it
> and/or implemented from the DOM Range specs deliberately made it
> support only one range (in incompatible UA-specific ways, naturally).
> Ehsan Akhgari, maintainer of the editor component for Gecko, is in
> favor of removing (user-visible) support for multiple selection ranges
> from Gecko, and last I heard no one objected in principle.  So the
> consensus of implementers is to support only one range.  As far as I
> know, the only reason Gecko still supports multiple ranges is because
> no one has gotten around to removing them.  (Ehsan would know more
> about that.)
I doubt we're going to remove support for multiple ranges, at least not internally.
If the standardized/stable web API will support only one range, then perhaps expose
only whatever primary range there is, but internally we need the functionality.
(and personally I think supporting multiple ranges is a good thing, and if there are
issues in an implementation, that shouldn't lead to weaker spec which doesn't support
them.)


-Olli


>
> The reason for all this is that while it makes wonderful theoretical
> sense to support multiple ranges for a selection, and is necessary for
> extremely sensible features like allowing a user to select columns of
> a table, multi-range selections are nonexistent in practice.  A
> selection that has multiple ranges in it is guaranteed to be
> mistreated by author code, because no one actually tests their code on
> multi-range selections.  More than that, Gecko code -- which is much
> higher-quality than typical author code and much more likely to take
> multiple ranges into account -- has tons of bugs with multi-range
> selections and behaves nonsensically in all sorts of cases.  So in
> practice, multi-range selections break everyone's code in the rare
> cases where they actually occur.  In general, an API that has a
> special case that will almost never occur is guaranteed to be used in
> a way that will break the special case, and that's very poor API
> design.
>
> In theory, a redesigned selection API that allows for non-contiguous
> selections *without* making them a special case would be great.
> Perhaps a list of selected nodes/character ranges.  But multiple
> ranges is not the way to do things.
>

Received on Monday, 12 January 2015 21:10:53 UTC