RE: Only Text Input and Intention Events: Return key

Great questions here. Let's make sure we're all on the same page first thought. The enter key is no different from any other key. It could be mapped to any Intention: insert newline character (\n), split the block (<p>), submit, create a unicorn (haha), whatever. ContentEditable shouldn't care what key is pressed, only what Intention is subsequently fired. We do not plan to have default browser behavior for block creation, submit, or unicorns, so only inserting characters should do anything here. If anyone thinks there is something special about the newline character, we should certainly discuss that. Finalizing an IME composition is another good point, but shouldn't that just be part of 'insert text'?

On Mon, Dec 1, 2014 at 11:50 PM, Frederico Knabben <f.knabben@cksource.com> wrote:
> As far as I understood, the insertion will not make any important DOM
> manipulation other than inserting a character (either inside a text node or
> by creating one). Therefore I don’t think that ENTER will be handled at all.
>
> The only exception may be ENTER inside <pre> (still limited to collapsed
> selections). Or may not, for consistency.
>
> Curious what others will say about it.
>
> --
> Frederico Knabben
> CKEditor Project Lead and CKSource Owner
> --
> CKSource - http://cksource.com

> --
> Follow us on: Twitter | Facebook | Google+ | LinkedIn
>
> On Monday, 1 December 2014 at 22:34, Norbert Lindenberg wrote:
>
>
> On Nov 25, 2014, at 11:11 , 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.
>
>
> Question on this * part: The Return key is used in many different ways, of
> which some should be handled as character insertion, while others are
> different operations. How does the browser detect what’s the intention?
>
> Some cases I can think of (and most of them have subcases):
>
> – The input method is currently composing text, so the Return key confirms
> the current composed text.
>
> – The selection is inside a PRE element, so a newline character is inserted
> into the element.
>
> – The selection is inside a P element, so the P element is split into two.
>
> – The selection starts in one P element and ends in a different one, so the
> selected text in these two P elements, as well as anything between them, is
> deleted, but the P elements remain separate and keep their attributes.
>
> – The selection is inside a TD element, so – well, whatever the application
> wants to do here.
>
> I’d see the first two as character insertion, while the others are not.
>

Received on Thursday, 4 December 2014 17:55:16 UTC