Re: [editing] selection across editing host boundaries

I filed bugs on this on both Firefox and Chrome in spring 2013. It was
briefly fixed in Chrome, but the fix was then retracted and we never heard
any more of it. It was also reported in Firefox by someone else in 2011. [1]

I also had some contact with Webkit people working in this area who
unfortunately didn't find the behavior to be problematic.

This is probably the main reason why at least I am wondering if editing
maybe just is an area that won't be of enough interest to browser makers to
ever fix and that it may therefore just make more sense to just ask them to
remove it and do everything in Javascript. But now it seeems this is about
to change, which would be really really good.

Use cases for this:

1. We use it for footnotes which we float of to the right of the text in a
<span class="footnote" contneteditable=false><span><span
contenteditable="true">[FOOTNOTE TEXT]</span></span></span>. If one has
access to CSS regions, one can even float them to be under the text on each
page. The other <span class="footnote"> is used to draw the footnote number
in the main text. If one hits backspace behind it, the entire footnote
should disappear. as it is now, instead the "back wall" of the footnote is
removed  which means that the rest of the paragraph is being added to the
footnote.


2. Figures with captions:

<div contenteditable=true>
  <p>blablablabla....</p>
  <figure contenteditable=false>
    <img src="...">
    <figcaption contenteditable=true></figcaption>
  </figure>
  <p>blablablabla....</p>
</div>



1) See
https://code.google.com/p/chromium/issues/detail?id=242110

https://code.google.com/p/chromium/issues/detail?id=238000

https://bugzilla.mozilla.org/show_bug.cgi?id=873883


On Mon, Jun 23, 2014 at 6:03 PM, Robin Berjon <robin@w3.org> wrote:

> 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
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.com