[editing] deletion and moving caret across stub and contenteditable=false elements (was: Re: [editing] nested contenteditable)

Ok, great!

Then I have three other, slightly related suggestions which I would be
interested in hearing your opinion about:

1. How should the stub elements images, canvas elements and inline SVGs be
treated in a contenteditable environment?

My suggestion is that they are treated the same: as if they were individual
letters. That means that moving the cursor across them (hitting right or
left while it the caret is directly to the right or left of it) should move
the cursor all the way across them, but no further. The caret should be
able to go between two stub elements, and before a stub element at the very
start of a paragraph and after a stub element at the very end of a
paragraph.

This is already the current behavior for  <img>-elements in IE10, Chrome
and FF.

Chrome fails at inline SVG elements, but handles canvas elements this way
already.
FF fails at canvas elements but handles inline SVG elements this way
already.
IE10 fails moving across canvas elements, but handles SVG elements this way
already.

See the first three examples of these bug reports:

https://bugzilla.mozilla.org/show_bug.cgi?id=873883
https://code.google.com/p/chromium/issues/detail?id=242110

2. How should contenteditable=false elements be handled that do not have a
nested contenteditable=true inside of them?

I suggest that they are handled the same way as those that do have a
contenteditable=true element inside of them wen it comes to
backspace/delete: if the caret is on one side of the element and the
backspace (when caret is on right side)/delete key (when caret is on left
side) is hit, they are selected entirely (as described in my previous
email). A second hit will remove them entirely. This is the way this
specification draft suggests handling tables.


3. What should happen if the caret moves across contenteditable=false
WITHOUT nested contenteditable=true elements?

I suggest that it should behave like stub elements (point 1).

This is already the behavior of Chrome.
FF moves across them, but jumps an extra letter.
IE10 jumps to the start of the contenteditable element.

The behavior of IE10 and FF does not seem sensible.

4. What should happen if the caret moves across contenteditable=false WITH
nested contenteditable=true elements?

I suggest the caret should move inside the nested elements asmit has been
described in previous specs.

None of the browsers seem to work very well with that scenario currently.

*) tested with Chrome 29, FF 21, IE 10.0.9200.16580


On Tue, May 28, 2013 at 1:27 PM, Travis Leithead <
travis.leithead@microsoft.com> wrote:

>  As far as I know, there is no actively maintained editing spec at the
> moment. Aryeh’s document is a great start but by no means should it be
> considered complete, or the standard to which you should target an
> implementation… I think we would [currently] prefer to discuss specific
> issues here on the mailing list until a regular editor can be found—so
> thanks for bringing this up!****
>
> ** **
>
> By the way, what you suggest sounds reasonable for the behavior.****
>
> ** **
>
> *From:* johanneswilm@gmail.com [mailto:johanneswilm@gmail.com<johanneswilm@gmail.com>]
> *On Behalf Of *Johannes Wilm
> *Sent:* Tuesday, May 28, 2013 6:36 AM
> *To:* public-webapps@w3.org; robin@w3.org; Alex Mogilevsky; Travis
> Leithead; ayg@aryeh.name; yosin@chromium.org
> *Subject:* [editing] nested contenteditable****
>
> ** **
>
> Hey,****
>
> is there any progress on finding out who is to maintain this spec:
> https://dvcs.w3.org/hg/editing/raw-file/tip/editing.htm ? Is Aryeh still
> a fulltime student?****
>
> ** **
>
> There is an effort at Chromium to make deletion of non-editable
> subelements work according to the spec, but the spec doesn't seem to
> anything about this. ****
>
> ** **
>
> See: https://code.google.com/p/chromium/issues/detail?id=238000
> ****
>
> ** **
>
> ** **
>
> Who could we ask to get the sepcification updated with information about
> this? ****
>
> ** **
>
> Our current suggestion is that backspacing/deleting into it selects it,
> and a second hit on backspace/delete will remove it. The most important to
> me though is to have clarity on this.****
>
> ** **
>
> ** **
>
> -- ****
>
> Johannes Wilm****
>
> Fidus Writer****
>
> http://www.fiduswriter.com****
>



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