Re: contentEditable=minimal

Thanks Jonas for clarification. Now, I understand contentEditable=minmal
doesn't modify DOM.

For drawing IME UI, text composition, Blink inserts text node with text
decoration to display on going text composition, IME UI. So, implementing
contentEditable=minimal, Blink should remove text nodes at commit of text
composition and dispatch text input event along with "beforeinput".Is this
correct?

-yosi


On Thu, May 22, 2014 at 5:52 PM, 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.
>
> 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
>
>