W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: contentEditable=minimal

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 22 May 2014 01:52:02 -0700
Message-ID: <CA+c2ei84rXVx_CEyYfyrPmOR5MJopsgXq-uJ0f5xT_i22DH9Hg@mail.gmail.com>
To: Ben Peters <Ben.Peters@microsoft.com>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, May 1, 2014 at 5:31 PM, Ben Peters <Ben.Peters@microsoft.com> wrote:
> Proposal
> To make this simpler for sites, frameworks, and browsers, it makes sense to enable a new, simpler version of contentEditable that provides basic functionality only. For the sake of discussion, call it contentEditable='minimal'. The functionality provided by the browser under contentEditable='minimal' would be as follows:
> * Caret drawing
> * Events such as Keyboard , Clipboard, Drag and Drop
> * Some keyboard input handling- caret movement, typing of characters including Input Method Editor input
> * Selection drawing and manipulation according to the new Selection API spec

This sounds like a super promising approach.

If I understand the proposal correctly, when the user does something
that causes input, like pressing the enter key, we would fire a key
event, but we wouldn't actually modify the DOM. Modifying the DOM
would be the responsibility of the web page.

Likewise, if the user pressed whatever key is platform convention for
"paste", we would fire an event which contains the clipboard data, but
not mutate the DOM. Copying data from the event (i.e. from the
clipboard) to the page would be the responsibility of the page.

Is that correct? If so I like it a lot!

I'd like to expand, and clarify, the list of services that you propose
that the UA provides:

* Caret and selection drawing.
* Drawing IME UI in response to user typing.
* Events for clipboard and drag'n'drop (though the UA would not mutate
the DOM in response to those events).
* Cursor navigation, including reacting to touch events, mouse clicks
and keyboard events. Cursor navigation would likely also fire
cancelable events.
* Turning keyboard events into events representing text input (but not
mutate the DOM in response to those events).
* The Selection API spec for selection manipulation.

I.e. pressing a key on the keyboard would always fire a keyboard
event, and then, as default action, possibly a cursor navigation event
or a text input event, depending on what type of key was pressed.

I'm unsure about what the proper way to handle text insertion is. I.e.
how to handle the second to last bullet.

Can we simply use the same events as we fire in <input type=text> and
<textarea>, but don't actually mutate any DOM? Or is it awkward to
fire "beforeinput" when there is no default action of mutating the DOM
and firing "input"?

And is it too much complexity to ask pages to deal with composition
handling themselves?

Another approach would be to allow plain text input events to actually
mutate the DOM as a default action. But allow that action to be
cancelled. Note that we would never do anything more complex than
mutate an existing text node, or insert a text node where the cursor
is located. I.e. no elements would ever get added, removed, split,
have attributes changed or otherwise be mutated.

But if we can make the code that a page needs to write in order to
handle the text mutation relatively simple, even when handling
composition, then I think we should leave it up to the page.

/ Jonas
Received on Thursday, 22 May 2014 08:53:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC