Merge pull request w3c#77 from w3c/editing-meeting-agenda

Update TPAC Editing meeting agenda

Author: chaals

meetings/16-09-22TPAC-3.md

@@ -28,9 +28,10 @@ This meeting will take place on 22 September 2016 as part of [TPAC 2016](https:/
 
 * Should we have an inputType for the spellchecker specifically? Previously we deicded to use a more general inputType for all possible spell- and grammarchechers which is now called insertNonText, but given that there are only spell checkers currently, it may be transport more information to use a new inputType like: "insertFromSpellcheck" [1]
 
-* Canceling last beforeinput event within compositions: Chrome teams's investigation found that browser could be made to remember dom structure before composition, but that this wouldn't hjelp much for cases where JS wants to handle insertion itself, because the revert would happen AFTER a beforeinput triggered piece of JS that calls event.preventDefault(). The problem with this is that it will require a dom-aware diffing mechanism on the JS side and may still include a fair amount of guesswork on the JS side [2]
+* Introduce inputType "deleteByComposition" and fire before "compositionstart" [[2]](https://github.com/w3c/input-events/issues/33)
+  * The original decision was to recover to the original state at the end of composition, but this wouldn't help much for cases where JS wants to handle insertion itself, because the revert would happen AFTER a beforeinput triggered piece of JS that calls event.preventDefault(). The problem with this is that it will require a dom-aware diffing mechanism on the JS side and may still include a fair amount of guesswork on the JS side
 
-Proposed solution: Add a method to this beforeinput event to revert the dom changes caused by the composition so that the DOM changes can be reverted before JS handling of composition insert [3]. Other ideas?
+* Introduce inputType "deleteCompositionText" and "insertFromComposition", fired right before "compositionend" [[3]](https://github.com/w3c/input-events/issues/34)
 
 * After the F2F in San Francisco, it was argued on the part of the Chrome team that the clipboard-related beforeinput events should only deal with dom-insertion and not with clipboard manipulation. These changes have been put into the spec draft. In that connection it was also argued that possible the history-stack-related beforeinput events possibly could be decoupled from the history stack. This would be somewhat different from the discussion at the F2F where the majority argued that the browser-internal history stack is unusable as soon as JS handles at least some types of editing operations. Is this something we need to reformulate in the spec, or does it not really matter, as undo/redo will have to be handled by JS anyway as long as JS preventDefaults some beforeinput events? [4]
 
@@ -40,32 +41,44 @@ Proposed solution: Add a method to this beforeinput event to revert the dom chan
 
 * [Clipboard API proposal](https://github.com/garykac/clipboard/blob/master/clipboard.md)
 
+* What inputType we should use for Enter key?
+  * Currently we are using 'insertParagraph' and 'insertLineBreak', but it might be confusing when pressing Enter in the middle of a heading element
+  * see https://github.com/w3c/editing/issues/149 Surprises #2
+
+  > When pressing the Enter key in the middle of a heading element, a beforeinput event with type==insertParagraph is fired. That's a bit unfortunate name, since often such input will be splitting different kind of blocks, inserting new list items or even outdenting lists. Therefore, in CKEditor, we decided to call this action "enter" as none other name suited it.
+
 #### Event order
 
 * Event order for drag/drop, history, clipboard: Should go into UI events spec? [7]
 
+* Event order between "deleteByDrag" and "insertFromDrop" ([see issue](https://github.com/w3c/input-events/issues/24#issuecomment-247453718))
+
 * When are the events triggered? Domenic Denicola and Anne van Kesteren declare "We don't want the timing of mutation events for any new events." Instead they favor tasks/microtasks [8]. How can this work for our events? Possibly three  microtasks where the first one (beforeinput event) schedules the second one (DOM mutation) only if it has not been preventDefaulted?
 
 * Anne van Kesteren proposes to move the prose about when the beforeinput/input events are fired into "n the specification that defines the action that causes the event to be dispatched. (UI events is rather bad in that it doesn't actually define actions, it just defines some events, some ordering between them, but nothing that amounts to a model.)" [9]
 
 
 ### Other issues
 
-* Format context menu on iOS/Safari, opt-in/out solution presentation of Apple's proposal. [10]
+* Format context menu on iOS/Safari, opt-in/out solution presentation of Apple's [proposal](https://github.com/w3c/input-events/issues/32#issuecomment-248762122). [10]
 
 * IME on long-key press, proposal on how to handle it? Wrap each keypress into an IME operation on Mac? [11]
 
 * Should contenteditable have break-word behavior by default? [12]
 
 * Clickability of elements with user-select: none [13]
 
-* Set virtual enter key text, presentation of Google's proposal. [14]
+* Set virtual enter key text, presentation of Google's [proposal](https://rawgit.com/dtapuska/action-hint/master/index.html). [14]
+
+* Set virtual keyboard type, presentation of Google's [proposal](https://rawgit.com/dtapuska/inputmode/master/index.html).
+
+* How to make undo/redo useful ([see issue](https://github.com/w3c/input-events/issues/36))
 
 [1] https://github.com/w3c/input-events/issues/31
 
-[2] https://github.com/w3c/input-events/issues/17#issuecomment-245739017
+[2] https://github.com/w3c/input-events/issues/33
 
-[3] https://github.com/w3c/input-events/issues/17#issuecomment-246102307
+[3] https://github.com/w3c/input-events/issues/34
 
 [4] https://github.com/w3c/input-events/issues/21