Re: [editing] selection across editing host boundaries

On Jun 24, 2014, at 6:39 AM, Piotr Koszuliński <p.koszulinski@cksource.com> wrote:

> 
> On Tue, Jun 24, 2014 at 12:34 PM, Robin Berjon <robin@w3.org> wrote:
> On 23/06/2014 20:33 , Johannes Wilm wrote:
> 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.
> 
> >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.
> 
> 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.
> 
> I am happy to see more cases that force us to propose something new, instead of patching rotting contentEditable=true :D.
>  
> 
> That's all nice and well, but what should the range be in the following cases:
> 
>   A:
>   <editable>blah <non-editable>foo</non-editable>| blah</editable>
> 
>   B:
>   <editable>blah [<non-editable>foo</non-editable>] blah</editable>
> 
>   C:
>   <editable>bl[ah <non-editable>foo</non-editable> bl]ah</editable>
> 
>   D:
>   <editable>blah <non-editable>f[oo</non-editable> bl]ah</editable>
> 
>   E:
>   <editable>blah <non-editable>|foo</non-editable> blah</editable>
> 
> Or in this:
> 
>   F:
>   <ul contenteditable=cursor>
>     <li>blah</li>
>     <li>|blah</li>
>   </ul>
> 
>   F2:
>   <ul contenteditable=cursor>
>     <li>blah</li>
>     <li>|</li>
>   </ul>
> 
> or just for kicks, one could make the argument that this is different:
> 
>   G:
>   <ul contenteditable=cursor>
>     <li contenteditable=cursor>blah</li>
>     <li contenteditable=cursor>|blah</li>
>   </ul>
> 
> ?
> 
> I think that we can start to solve this in the following manner:
> 
>   • When a deletion event would produce a range crossing an odd number of editing boundaries (either because there's a selection doing so in the sum of its ranges or for instance given backspace in case A above) then its range is empty and corresponds to a collapsed range a the cursor position (this is defined even for selections).
> 
>   • Conversely, when it would cross an even number of editing boundaries, then the range covers them.
> 
>   • Deletion events capture information expressing the direction of the deletion ("previous", "next", or possibly "both" in the delete-line case). This makes it possible for script to know how to hand the empty-range case.
> 
>   • Additionally, the deletion event can expose convenient information about the editing boundaries being crossed, their number, their hosts.

Could you list use cases that support the above behaviors?  I agree all these recent discussions about editing is great but I've got a feeling that we've been spending too much time talking about solutions without really understanding use cases and the full scope of the problem we're trying to solve.


> This means that, assuming backspace, the cases above can be handled as follows:
> 
> A: empty range, the script can decide whether to select or delete the non-editable content (direction "previous").
> B: a range containing non-editable. Presumably deleted.
> C: same as B with some extra content on both sides. Presumably deleted.
> D: empty range, the script can decide what makes most sense. (Stabbing the user in the face sounds good.)
> E: empty range, the script decides which is best.
> 
> For F, F2, G, and an awful lot of other cases (dt/dd, td, etc.) I think we should take the minimalist approach: just produce a deletion event indicating its direction but with an empty range. Scripts can decide if they wish to merge elements, delete empty ones, outdent, etc.
> 
> 
> This is getting complicated enough (and I haven't mentioned other cases such as br, script, hr, td, img, video...) that I wonder if the Deletion event shouldn't have its own spec.
> 
> I agree about A, B and C. Selection in D in my opinion should not be possible (I'll comment on that later [1]). Selection in E also should not be possible because empty selection can't be made in non-editable element.

It does seem that disallowing selections that cross odd numbers of editing boundaries would simplify the issue.  Perhaps UA could auto-correct such selections before presenting it to the user so that the user would not get confused by editing actions not being applied to the entirely of such selection.

I do see one benefit in true current Blink/WebKit behaviors of treating nested editing hosts as if they're a single editing host in that users would have no idea whether two editable regions are composed of two different elements or not.  However, I don't think it's that common for websites to have nested editing hosts without any visual cue that they're separate elements so this might be an important thing to consider.

Could someone file a bug against Selection API specification to specify this behavior?

- R. Niwa