RE: contentEditable=minimal

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

Yes this is the idea.

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

Agree on all counts.

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

As mentioned on another mail, I think a corollary for document.execCommand('insertText') would be good. For instance, CommandEvent with type="insertText" that contains the text to be inserted.

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

BeforeInput is not my favorite right now, but I'm totally open. Reasons for this:
* As you said, nothing is about to be inserted
* It fires after other Intention-style events like ClipboardEvent, so it will be double-handled
* It's not a clear corollary to the invoke side, which is execCommand.

> 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 23:31:02 UTC