Re: Only Text Input and Intention Events

On Wednesday, 26 November 2014 at 21:03, Olivier Forget wrote:
> I think the text should go exactly at the position that is reported by window.getSelection(). So if the anchorNode is the text node inside the <a>, then typing will go inside the <a>.
>  
> Problems might occur when the selection anchor is an Element instead of a text node. Does that mean put text inside? after? before?
>  
> Ben was thinking that the text insert default behavior should only take place if the selection is collapsed. We could add the requirement that the selection anchor node must be a text node. The text would be inserted in selection.anchorNode, at position selection.anchorOffset. Rationale:
> - maps nicely with existing api for selections
> - absolutely no question where the text is going to go
> - no magically appearing text nodes.
> - Editor devs can control where text can go. If you don't want user to add text between a <table> and a <p>, you can prevent that by not putting any text nodes there.
>  
> Caveat: there are existing issues with setting selection at offset 0 of text nodes, or in empty text nodes which become more pronounced if text nodes become so central to editing. Should we try to address these here?
I think this starts too get a bit confusing.  

The suggestion for making it work on collapsed selections only is great. +1

As for the anchorNode problem, there is little to be though I thing, because the insertion is a pretty simple procedure:

1. Check if selection is collapsed.
2. Insert the character exactly at anchorNode+anchorOffset position.

Note that “2” will push the current “thing” present in anchorOffset to anchorOffset++.

Example 1:

- Before insert:
anchorNode = ‘Lorem ipsum’ (text node)
anchorOffset = 3 (‘e’)
- Insert ‘X’
- After insert:
anchorNode = 'LorXem ipsum’ (text node)
anchorOffset = 4 (‘e’)


Example 2

- Before insert:
anchorNode = <p><i>Sample </i><b>text</b></p> (element)
anchorOffset = 1 (<b>text</b>)
- Insert ‘X’
- After insert:
anchorNode = <p><i>Sample </i>X<b>text</b></p> (element)
anchorOffset = 2 (<b>text</b>)

So, there is no “if” here… the same approach is taken for both text nodes and elements.

Ofc, the browser will have to inject a new text node if necessary.

And yes, the selection after insert is changed (anchorOffset++). It should be even ok to normalize it and move it inside a text node, if applicable.
> - Editor devs can control where text can go. If you don't want user to add text between a <table> and a <p>, you can prevent that by not putting any text nodes there.


Having to do this through injection of text nodes would be plain hacky. Instead, this should be as simple as preventing the insertion intention.


Does this make sense?

--
Frederico Knabben
CKEditor Project Lead and CKSource Owner
--
CKSource - http://cksource.com
--
Follow us on: Twitter (http://twitter.com/ckeditor) | Facebook (http://www.facebook.com/ckeditor) | Google+ (https://plus.google.com/107736718646302128806) | LinkedIn (http://www.linkedin.com/company/cksource)