meeting in Berlin (late May or June)?

Hey,
as I'm going through the remaining issues, it seems like there are still a
number of issues we need to deal with to get a good input events spec up
and running. The following are things I came across while going through the
issues on github. Maybe some of these things can be dealt with quickly
here, but there are likely other issues I haven't thought about so far.

What do people think? Would a meeting in Berlin in late May or June be of
interest?

1. Dragging and dropping:
-- What should the order of the events be and in what spec should this be
placed?

2. Clipboard events:
-- Should paste and cut have beforeInput events?
-- If yes, should these be cancelable? Only in cE=events or also in cE=true?
-- Should copy also have a beforeInput event? If yes, also if there is no
editing host involved?

3.  History handling (undo/redo)
-- What should the relationship between browser-controlled editing history
and beforeInput event be? Should redo/undo have beforeInput events?
-- If JS handles beforeInput events, should the browser try to figure out
what changes were made? Is that technically possible?

4. Non-cancelable event
-- Previously we talked about the beforeInput event not being cancelable
during a composition. With the splitting of the event into one part in the
ui-events spec and the other in the Input events spec, the cancelable
attribute is in the ui events spec and the isComposing is in the Input
events spec. In the ui-events spec the event is marked as always being
cancelable. Will this work, or do we need to specify that it is not
cancelable during composition?

5. static ranges
-- A non-finalized proposal has been made by the browser meeting in January
[1] and there is also FrozenArray (?) [2].
-- We have moved back and forth between ranges on most beforeInput events
or only using it if it differs from the current selection. We need to
decide one.

6. Opt-in/opt-out of editing features and menus
Context menus currently exist for formatting (on Safari) and for clipboard
related actions (other browsers)
-- These three points could possibly be combined into a proposal that work
for everyone:
A. JS editor developers have asked for a way to be able to disable context
menus (especially on mobile).
B. Hallvord Steen (Clipboard API) has defined a way to define how to
disable clipboard actions in the standard context menu (beforeCopy,
beforePaste, etc. events which are triggered at the moment the menu is
potentially shown) but he is not happy with the implementation and wonders
if we could do something better in the editing taskforce.
C. It has been proposed at the editing meeting at TPAC to create a way to
opt-in/out of features which would then also disable/enable corresponding
editing menus [3].
-- Which spec should this go into? (input events being one option)

7. Relation to execCommand
-- Does it really make sense to try to cover all execCommand commands with
beforeInput types [4]? How about "copy" which doesn't change the DOM, or
commands such as "insertImage" or "foreColor" which will recreate custom UI
anyway?

[1] https://github.com/w3c/editing/issues/104
[2] https://github.com/w3c/editing/issues/113
[3] https://github.com/w3c/editing/issues/93
[4] https://github.com/w3c/editing/issues/79

-- 
Johannes Wilm
http://www.johanneswilm.org
tel: +1 (520) 399 8880