Re: contentEditable=minimal

On 22/05/14 09:52, Jonas Sicking 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.
>
> 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).

Ideally, we also would have events for undo and redo as generated by the 
browser's native UI, e.g. the chrome undo/redo menu items where these 
are provided by the browser.  This is important as it allows a web page 
to manage its own undo/redo stack.

> * 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).
Yes, as this would allow browser based editors to take advantage of 
native input methods and avoid a dependency on the keyboard.

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

Getting the events, but not modifying the DOM sounds great.

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

No, but it is definitely something where a few excellent libraries would 
be expected to be widely used.


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

Simple text entry is easy, but Enter, Backspace and Delete are 
surprisingly hard, as I have found out in writing a cross browser 
library that takes over the handling of these keys, since my experiments 
showed that browsers varied in their treatment of them, and that 
browsers frequently don't behave in the way that people expect with 
common word processing software.

-- 
   Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett

Received on Thursday, 22 May 2014 16:01:17 UTC