[webkit-dev] Selection model is broken

[Ojan Vafai]

On Thu, Jan 5, 2012 at 3:47 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

> On Thu, Jan 5, 2012 at 3:31 PM, Ojan Vafai <ojan at chromium.org> wrote:
>
>> Selections on the web are document ordered (i.e. all the DOM between two
>> points). So, any CSS that puts elements out of document order gives a
>> crappy selection to the user.
>>
>> <div style="position:relative">foo<div
>> style="position:absolute;left:-100px">bar</div>baz</div>.
>>
>> If you select "foobaz", clearly no user would expect "bar" to get
>> selected. The same problem arises with floats, negative margins, flexbox
>> and grid ordering. I expect it's likely that CSS will continue to get more
>> ways to put elements out of document order.
>>
>
> The same behavior arises from bidirectional text as well.
>

bidi is a different case. It has to do with user-insertion. The user
inserts it in document order, so it makes sense to select it in document
order. It does lead to crazy looking selections, but they are selections
that make sense to bidi-users.

The only solution I can think of to this is to create a hit-test rect when
>> making a selection from the start point to the end point and then only
>> include the DOM contents that overlaps the rect. We'd still include all the
>> inline content of overlapping elements, but elements that don't overlap at
>> all would be excluded.
>>
>> So, instead of a selection being a start and end DOM position, it would
>> be a list of disjoint start and end DOM positions.
>>
>
> That's exactly what a multi-range selection is.
>
> Does this seem technically feasible? I think we can get the APIs exposed
>> to JS to work with this if we are willing to make the change.
>>
>
> Gecko already have such an API.
>

Sure, but Gecko only uses it for selecting table columns, right? Otherwise,
selections in Gecko are document ordered and between to points in the DOM.


> The big pro is that selections will be much more intuitive for a large and
>> growing class of layouts.
>>
>> Cons:
>> -Making a selection is slower now and involves hit-testing a full rect
>> instead of just two points. (is this even possible?)
>> -The code that deals with selections now needs to operate on multiple
>> selections (e.g. hitting delete in an editable area needs to separately
>> delete each sub-range).
>> -JavaScript code that operates on selections may need to change. Or maybe
>> we need to add new APIs in order to maintain backwards compatibility for
>> the old APIs.
>>
>
> Also, once user can select such content, they'd expect to be able to copy
> & paste that content. In fact, the most probable reason an user selects
> text is to copy it.
>
> However, when relatively positioned, flexbox, etc... are involved, there's
> virtually no way for us to ensure the pasted content will maintain the
> visual order. So users would get crappy experience anyways.
>

It's true, but I think this is a less crappy experience. In these cases we
could either try to copy in visual order or just paste out of order. It's
not perfect, but it's better a better experience than selecting text that
the user clearly didn't want selected.

Also, what should happen, for example, if those contents appear inside a
> contenteditable region and the user hits delete, paste, insert a character,
> etc...
>

Yup. We have to handle all these cases appropriately. Copy is the only hard
case IMO. Delete is implemented as deleting each sub-range individually and
then collapsing the selection at the beginning of the first range. For all
the other cases, you do a delete and then insert into the now collapsed
selection.

Is this too crazy? Are there other solutions?
>>
>
> I'm strongly opposed to the idea of supporting multi-range selection. It's
> not worth the complexity and we'll never get it right.
>

We'll never get it 100% right, but we can get much much closer than we do
today and with the increasing number of cases that hit this, it becomes
more important that we do get this right.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120105/5c8b8bc9/attachment.html>