Re: contentEditable=minimal

On May 22, 2014, at 1:52 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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.

I agree.

> 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 think it'll be nice to allow authors to enable default UA actions; e.g. auto paste into DOM.

> 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?

I think requiring pages to handle composition events will be bad because many people don't even know how input methods work, or for that latter, what input method is.

> 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.

I think it would be nice for authors to explicitly enable such default behaviors.

- R. Niwa

Received on Thursday, 5 June 2014 06:51:51 UTC