Re: Only Text Input and Intention Events: Return key

I agree with Frederico. All control codes should not be handled,
including ENTER and TAB. Today I had some informal discussion with my
colleague about whether it should handle BACKSPACE/DEL or not. I think
it should not, but he disagreed with me. There might be some
controversial keys, but I think we can discuss them and resolve as Ben
puts them into the spec.

My basic idea is that this spec is similar to OS APIs; if an API can
be built upon other APIs, don't add that. Such APIs should be added to
user libraries. In our case, browsers should do only fundamental and
predictable tasks, with no magic. It is likely to be inconvenient for
end user point of view, but I think such design works better for
framework developers.

For the specific example of ENTER inside <pre>, I don't think we
should make it the exception, not only for the consistency, but also
for the stability of the fundamental block since the CSS white-space
property[1] is evolving in Level 3, and maybe further in Level 4.

I look forward to this spec going forward quickly, reach to FPWD, and
go on the REC track even further.

[1] http://dev.w3.org/csswg/css-text/#white-space-property

/koji

On Tue, Dec 2, 2014 at 4: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.
>
> Norbert
>
>

Received on Thursday, 4 December 2014 13:07:44 UTC