- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Fri, 06 Jun 2014 09:52:34 -0700
- To: Robin Berjon <robin@w3.org>
- Cc: Ben Peters <Ben.Peters@microsoft.com>, Norbert Lindenberg <w3@lindenbergsoftware.com>, Jonas Sicking <jonas@sicking.cc>, Piotr Koszuliński <p.koszulinski@cksource.com>, public-webapps <public-webapps@w3.org>
On Jun 6, 2014, at 6:40 AM, Robin Berjon <robin@w3.org> wrote: > On 05/06/2014 09:02 , Ryosuke Niwa wrote: >> I agree visual selection of bidirectional text is a problem worth >> solving but I don't think adding a generic multi-range selection >> support to the degree Gecko does is the right solution. > > I'd be interested to hear how you propose to solve it in another manner. Also note that that's not the only use case, there are other possibilities for disjoint selections, e.g. a table (naturally) or an editable surface with a non-editable island inside. Supporting disjoint range is probably necessary but adding the ability to manipulate each range separately seems excessive because that'll lead to selections with overlapping ranges, ranges in completely different locations that are not visually disjoint, etc... We might need to do something like exposing readonly multi-range selection. >> For starters, most of author scripts completely ignore all but the first >> range, and applying editing operations to a multi-range selection is >> a nightmare. > > I don't disagree that it can be hard to handle, but I'm not sure that that's indicative of anything. Most scripts only handle one selection because AFAIK only Gecko ever supported more than one. Given Gecko itself doesn't handle applying editing operations to multiple ranges well from what I've heard, I'm not certain we can expect web developers to get them right especially in the context where disjoint multi-range selection is needed; e.g. bidirectional text, exotic layout model. - R. Niwa
Received on Friday, 6 June 2014 16:53:24 UTC