- From: Ben Peters <Ben.Peters@microsoft.com>
- Date: Thu, 22 May 2014 23:30:30 +0000
- To: Jonas Sicking <jonas@sicking.cc>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
> 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