On 22/05/2014 10:52 , Jonas Sicking wrote:
This sounds like a super promising approach.
\o/
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.
That is the point yes. Using the DOM as both the model and view does not make sense for all editing, and this makes it possible to separate the two without hacks that override the browser.
Your example of the enter key is, of course, one of the annoying ones. Sometimes you want a new line, sometimes you want the next element, sometimes you just want to navigate to the cell below.
Enter may be a case in which a higher-level event is required so that you can respect the platform's convention for Enter vs Ctrl-Enter for instance.
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!
Entirely correct. Again, \o/.
I'd like to expand, and clarify, the list of services that you propose that the UA provides: * Caret and selection drawing.
Yes. And reporting that information accurately to the application (which can be pretty tricky for multi-range selections in tables or at bidi boundaries).
cE=minimal enables caret drawing, the rest is done through the Selection API.
* Drawing IME UI in response to user typing.
Where applicable, yes. I would expect the IME API to play well here.
* Events for clipboard and drag'n'drop (though the UA would not mutate the DOM in response to those events).
Yes. ClipOps and DnD APIs.
* Cursor navigation, including reacting to touch events, mouse clicks and keyboard events. Cursor navigation would likely also fire cancelable events.
Yes. Cursor navigation can be represented through selections (that may be collapsed). In general it is important that selection changes can be cancelled so that developers can carry out selection validation before accepting it.
Making some things unselectable might also be useful. IE has unselectable, there's also -moz-user-select and friends. But this is small fries for later I'd reckon.
* Turning keyboard events into events representing text input (but not mutate the DOM in response to those events).
Yes, possibly in a rather advanced manner.
* The Selection API spec for selection manipulation.
Right.
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"?
Isn't that just a question of whether to reuse the same event name or pick a new one?
And is it too much complexity to ask pages to deal with composition handling themselves?
I think it's too much to ask for them to deal with composition, but they should deal with composition events. See my earlier posts for details.
Dealing with composition events is certainly a bit of effort (not much though — the hardest part is knowing they exist) but we want to go low-level here. I think it's an acceptable level of complexity for library authors.
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 don't think you can do that without ending up weird places. "No elements would ever get mutated" -> what happens if I have a selection that contains an element (or parts of it)? Very quickly you'd end up either having to make the browser manipulate the DOM yourself (bad, really really bad), or in a situation in which some text events have a default action and some don't depending on the current state of the selection (possibly even worse).
It's very tempting to try to "do more" for developer here, but I really think we should resist this impulse lest we end up with the a new mess that just works differently.
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.
I think that we can make it reasonably easy to handle composition by using composition events.
-- Robin Berjon - http://berjon.com/ - @robinberjon
