- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Mon, 5 Aug 2013 16:45:32 +0300
- To: Mihnea-Vlad Ovidenie <mihnea@adobe.com>
- Cc: public-webapps <public-webapps@w3.org>
On Mon, Aug 5, 2013 at 10:25 AM, Mihnea-Vlad Ovidenie <mihnea@adobe.com> wrote: > I would like to know more about the corner cases mentioned above and the > problems encountered when trying to implement this feature. Are they > documented somewhere I can take a look? The basic issue is that in ~100% of cases, the selection will contain only one range, so both web developer and implementer code will not be written with the multi-range case in mind and will therefore not handle it properly. There's lots of code inside Gecko itself that just handles only the first range and ignores all others. I'm also pretty sure I remember fixing some code once that iterated over the selection's ranges incorrectly in such a fashion that it crashed if there were multiple ranges -- the case was just never hit in testing, so no one noticed for years. And this is of course better than web developer-written code, which in my experience universally assumes .rangeCount is always either 0 or 1. Allowing non-contiguous selections is a very useful feature and would be great to support, not just for regions but even for more basic things like selecting a column of a table. But the way it's exposed by the API is unusable in practice. A better API would ensure that non-contiguous selections are not a special case -- for instance, exposing a list of selected nodes/data characters instead of a range. The code iterating over the selected items wouldn't have to behave differently depending on whether the selection is contiguous. You can't expect anyone to properly test codepaths that are only hit when the user has selected a table column. On top of that, it's also not always trivial to write code that properly supports multiple ranges. Suppose I write some code that indents the selection by wrapping the selected block(s) in <blockquote>. To support multiple ranges, I couldn't just take the one-range case and run it separately over each range, because if I had <p>[foo] bar [baz]</p> (both "foo" and "baz" selected in the same paragraph), that would indent the same paragraph twice. I'd have to rewrite the code to obtain a list of blocks to indent for each range separately, delete duplicates, and only then indent, or something like that. It is not reasonable to expect anyone to even try to do this for such a small corner case as multiple ranges in the selection, let alone to do it correctly.
Received on Monday, 5 August 2013 13:46:30 UTC