Re: Only Text Input and Intention Events

On Wed, Nov 26, 2014 at 12:27 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> Also sounds good to me.
> What happens if the caret is at the end/right behind a link/bold
> text/italic text?  Does the text go inside the link/bold/italic or outside
> it? It may not matter that much which one you choose, as long as it is
> consistent.
>
> Good question.

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?


> On Wed, Nov 26, 2014 at 1:22 AM, Olivier Forget <teleclimber@gmail.com>
> wrote:
>
>> That would work for me.
>>
>>
>> On Tue, Nov 25, 2014, 3:39 PM Ben Peters <Ben.Peters@microsoft.com>
>> wrote:
>>
>>>  Great question. I think we should fire a “replace” or “insert”
>>> intention (via beforeInput) that has the following default behavior:
>>>
>>>
>>>
>>> 1)      If the selection is not collapsed, abort these steps
>>>
>>> 2)      Insert text (which needs more detail)
>>>
>>>
>>>
>>> This way there is no ambiguity, and authors don’t have to handle
>>> inserttext and IMEs. They just have to clear the selection in the intention
>>> event handler and then let the browser do the rest.
>>>
>>>
>>>
>>> *From:* Olivier Forget [mailto:teleclimber@gmail.com]
>>> *Sent:* Tuesday, November 25, 2014 3:35 PM
>>> *To:* Ben Peters; public-editing-tf
>>> *Subject:* Re: Only Text Input and Intention Events
>>>
>>>
>>>
>>> Hi Ben,
>>>
>>> Sounds good to me. Question though: in your view of things, what is the
>>> default behavior if user inputs text while some content is selected?
>>>
>>> On Tue, Nov 25, 2014, 11:12 AM Ben Peters <Ben.Peters@microsoft.com>
>>> wrote:
>>>
>>>  Let’s bring this conversation full circle. I think the first thing we
>>> should do is create a new type of contentEditable that only supports
>>> inserting characters by default. If a user types using an IME, keyboard,
>>> speech, etc, the browser fires beforeInput with the characters to insert
>>> and then inserts them by default. For anything else* the browser fires
>>> beforeInput with context data and then does nothing by default. The key is
>>> that all types of input can be handled in script by responding to Intention
>>> Events, with the exception of IME input, which means only character
>>> insertion should have a default behavior. If there are low-level apis we
>>> need to make this possible, we’ll create them going forward. If this sounds
>>> like a reasonable V1, let’s get it spec’d and taken to FPWD.
>>>
>>>
>>>
>>> *Things that have no default behavior in V1: newlines, deletion,
>>> formatting, pasting, inserting html, etc.
>>>
>>>
>>>
>>> Ben
>>>
>>>
>>>
>>>
>
>
> --
> Johannes Wilm
> Fidus Writer
> http://www.fiduswriter.org
>