- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Sat, 10 Jan 2015 18:30:11 +0200
- To: Olivier Forget <teleclimber@gmail.com>
- Cc: Ryosuke Niwa <rniwa@apple.com>, Koji Ishii <kojiishi@gmail.com>, Webapps WG <public-webapps@w3.org>
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.) 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 Saturday, 10 January 2015 16:31:01 UTC