Re: [editing] selection across editing host boundaries

On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon <robin@w3.org> wrote:
<snip>

>
> From discussions I've had in the past on this topic, it's not so much that
> browser-folks don't want to fix this. The problem is more that 1) this is
> hard, so fixing can often only happen if someone really owns the problem
> rather than contributing the odd fix, and such a person isn't always
> available; 2) the current state of contentEditable is such a mess, notably
> with libraries doing per-UA workarounds, that fixes that make the behaviour
> globally saner actually break deployed code.
>

Don't worry. I don't think browser people are evil. :) It may just be that
this isn't a priority for browser makers, as it's not that widely used, and
CkEditor/TinyMCE are doing a good job most places.



>
> This has conspired to make the situation rot. Hopefully we can fix this
> with the new tack taken here, notably by using contentEditable=cursor as a
> "sanity hook" which doesn't have to be backwards compatible with the
> existing madness.
>
> You point to several bugs, but I think the one most worth reading is:
>
>     https://code.google.com/p/chromium/issues/detail?id=238000
>
> This has a wealth of issues and information, as well as a number of good
> ideas. Piotr's point about the behaviour of deletion when a selection
> crosses an even number of editing boundaries is particularly useful.
>

Deletion is indeed a difficult thing and I would estimate that maybe half
of our code that deals with contenteditable deals with backspace, del, and
the error keys in some way or another.



> The way we've been thinking about this so far is that with cE=cursor, the
> browser would perform no DOM modification on your behalf but rather you'd
> have to handle events in order to carry out the modifications yourself.
> This increases the amount of work that script has to do but in this case it
> would likely enable you to produce the precise handling you require.


> Having said that, considering this specific problem makes me realise that
> the deletion event model that I had in mind does not work.

<snip>

> Thoughts?


Yes, exactly. All your proposals sound fine concerning this.

Yet even if it's up to the javascript library to decide what should happen,
it would still be nice to have some kind of standard behavior defined so
that web users get used to one way. For example, it was mentioned several
times in various discussions that del/backspace in the case of "complex
elements" that are being treated as a single character when it comes to
cursor movement, should be selected rather than deleted if the range is
empty. A second press on backspace or delete will then delete them and
collapse the selection range. This was what the previous draft on cursor
movement in  contenteditable said about tables. It doesn't need to
specifically be that way, but it could. Wikimedia have implemented this in
their latest attempt at a WYSIWYG editor:
https://en.wikipedia.org/w/index.php?title=Repulsion_theory&veaction=edit
(try deleting the "[2]" with the cursor either in front or behind it). I
would think that elements involving several editing boundaries should in
just about all cases be classified as "complex elements".

>
>
>
>  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.
>>
>
> A question for you: how would you like selection to work in this case,
> notably for copy/pasting? As a user, I would tend to expect that if I
> select from before the <sup>1</sup> to after it and copy, I would get a
> buffer containing the <sup>1</sup> but *not* the footnote content
> (otherwise you get the famed "PDF effect" with lots of junk in your
> buffer). It also looks visually weird if you have the footnote to the side
> of the page being selected. But with the logical document order you use, it
> would get selected. Do you make use of selection-preventing tricks?
>

Actually in our case, we would expect for the footnote and its contents to
also be selected and copied along with the main text that surrounds it.
 But our use case may be very specific and different from how others use
footnotes: In our case the student/academic decides that two paragraphs
from the beginning of chapter 2 should be moved to the end of chapter 4
instead. The footnotes should move along with the main text, and should
therefor be part of the selection-copy-paste process.

*Placing footnotes to the right/left of the main text was a solution we
found when it became clear that CSS Regions would be removed from Chrome.
Previously we "flowed" them to below the text for Chrome and Safari users.
However, it now turns out that while footnotes make sense at the bottom of
a printed page, in the case of an editor, it's not always convenient to
have to scroll down to read a footnote and then back up again to continue
reading the main text. A little piece of Javascript that maintains a
page-wide CSS-deifnition makes sure that the footnotes never overlap.*


>
> These likely have their own amusing interactions with deletion: if you
> make the footnote non-selectable but wish to drop it when a selection
> encompassing it is deleted, you're facing a fun new challenge.
>
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>



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