[editing] selection across editing host boundaries

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.

See http://jsfiddle.net/3LzKU/ for test cases, the editing host is
composed of an outer element with contenteditable=false and an inner one
with contenteditable=true (see note for reasons). Case 0 is non-editable
content embedded in an editing host (to see browser behaviour in the
base case), case 1 is as described above, cases 2 and 3 add whitespace
(through padding and margin) to see if behaviour differs from case 1 (it
does not) and case 4 adds read-only textual content (provides additional
insight regarding DOM shifting during edition across the boundary)

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.

Note:
  [editing] and browsers seem to disagree on what an editing host is:
  unless I’m misreading the spec, a direct child of an editing host with
  @contenteditable=true should be an editing host itself. Thus <span
  contenteditable=true><span contenteditable=true> would be 2 editing
  hosts, one within the other. No browser seems to treat the inner node as
  an editing host as boundary behaviours don’t appear.

[editing] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
[cke] I believe the latest “ckeditor” release provides a system of
      “widgets” working along the lines outlined there.

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.

Received on Monday, 9 June 2014 20:22:48 UTC