Re: [editing] selection across editing host boundaries

On 07/06/2014 15:15 , Xavier Morel wrote:
> I’ve been working with @contenteditable and I’ve hit a case where
> one browser family (Webkit) seems to behave very differently than the
> others (tested: Firefox and MSIE). The situation is nested editing
> hosts: when starting a selection from the inner editing host, the
> selection stops at the host boundary in all cases. However when starting
> the selection from the outer editing host and entering the inner one,
>
> * MSIE and Gecko treat the inner editing host as an opaque item (a
>    character, or a non-editable element embedded in the editable one),
>    either none of the inner host is selected or all of it is part of
>    the overall selection
>
> * Webkit-ish browsers (Safari and Chrome) on the other hand extend the
>    selection within the inner editing host (so the selection can be half in
>    and half out)
>
> The issue is, in the case of webkit browsers, when an edition is then
> performed they start moving stuff across the editing host boundary, and
> text goes in or out of the inner host (depending on the direction of the
> selection), generally ending up in an unrecoverable mess and panicking
> the end user.

Urgh, that's horrible. Indeed, it needs to be fixed.

> Now the use-case for the situation is the edition of a document (or
> document section) in which sub-sections with differing edition
> constraints are embedded e.g. content sections which may not be
> formatted (even though the top-level may), sections which may only be
> edited via a specific interface (e.g. embedded video + controls,
> embedded slides or graph) or section with other edition restrictions
> (e.g. only an enumerated set of values allowed), or even edition of more
> “template”-oriented systems with restricted blocks (providing
> template logic) containing free-form document sections[cke].
>
>  From my testing and use cases so far, I would say that the MSIE/Gecko
> behaviour is sensible and has the advantage of being uniform, whether
> a non-editable section contains editable descendants or not, it is
> also significantly less likely to destroy user content. But I would
> like to know what other people think of it, and whether an issue
> should be opened on the webkit and chromium trackers.

I think that there are several distinct things that should help here.

First, I believe that we should clearly define that when you have a 
selection that goes outside of a given editing host then the editing 
commands don't reach it. Put differently, you can only receive those 
events if you have focus, and you can only be focused if the current 
selection is *entirely* contained inside of you. A larger container 
might get keyboard events, but that's it.

Second, I think that it would be helpful to put the selectability of 
some elements under user controls. (With which mechanism is another 
question. IE does it with an attribute, others through CSS. I don't 
think it's a styling decision.)

As part of that it might be useful for non-editable islands/nested hosts 
to state how they should react to ensconcing selections. For instance, 
if I have a paragraph and a figure inside a section, I might refuse to 
carry out any editing action when I have a selection that goes from half 
of one to half of the other; but if both are fully selected as part of 
the section I might wish to delete them.

I wonder if we could list a set of use cases for this sort of 
interaction and figure out how best to handle them. It is related to 
something I've often wanted to do with editing. Assume you have two 
content items inside a section, and since they have different 
constraints they are editable separately (horrible markup just for 
example purposes):

<section>
   <p contentEditable=true>
     A thing of beauty is a joy forever.
   </p>
   <div class=poem contentEditable=true>
     <div class=line>Time will say nothing</div>
     <div class=line>But I told you so</div>
   </div>
</section>

At this point, if I have my cursor right after the "y" of "say" in the 
first poem line and arrow up, I would like the cursor to go, roughly, 
after the "e" in "beauty". In existing systems it is far more likely to 
wind up right before "Time". Maybe that could be differentiated thusly:

<section contentEditable=minimal>
   <p contentEditable=minimal>
     A thing of beauty is a joy forever.
   </p>
   <div class=poem contentEditable=minimal>
     <div class=line>Time will say nothing</div>
     <div class=line>But I told you so</div>
   </div>
</section>

In other words, the presence of a containing host would influence the 
behaviour of cursors at (inner) editing boundaries. And as indicated 
above, my script could refuse to do anything for a selection from "joy" 
to "nothing" (since the operation might be meaningless across the nested 
contexts) but it might respond to deletion if both the p and div.poem 
are fully selected.

> PS: I am not subscribed to the list, if anybody is interested and wants
>      to reply or has further questions, I'd be grateful if you could CC
>      me.

Maybe you'll be interested in signing up to the new public-editing-tf 
list which has much lower traffic.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Monday, 23 June 2014 16:04:05 UTC