Re: topics for Fridays F2F

This is the current agenda is below. Also available here<https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-29-Editing.md>.


Dragging and dropping
What should the order of the events be and in what spec should this be placed?
Clipboard events
Should paste and cut have beforeInput events? If so, should these be cancelable? Only in cE=events or also in cE=true?
Should copy also have a beforeInput event? What if there is no editing host involved?
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?
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?
static ranges
A < href="https://github.com/w3c/editing/issues/104">non-finalized<https://github.com/w3c/editing/issues/104%22%3Enon-finalized> proposal was made at the browser meeting in January, and there is FrozenArray<https://github.com/w3c/editing/issues/104> (?)
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.
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 works for everyone

  *   JS editor developers have asked for a way to be able to disable context menus (especially on mobile).
  *   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.
  *   It was proposed<https://github.com/w3c/editing/issues/93> 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
  *   Which spec should this go into? (input events being one option)

Relation to execCommand
Does it really make sense to try to cover all execCommand commands with beforeInput types<https://github.com/w3c/editing/issues/79>? How about "copy" which doesn't change the DOM, or commands such as "insertImage" or "foreColor" which will recreate custom UI anyway?

Publishing
It would be good to get First Public Working Drafts of the things we are working on


Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Ojan Vafai <ojan@google.com>
Sent: Tuesday, July 26, 2016 11:38:33 AM
To: public-editing-tf@w3.org
Subject: topics for Fridays F2F

Is anyone putting together an agenda?

At the top of my list is resolving any open issues with beforeInput. I'd like to ship that soon in Chrome (e.g. in the next month or two), so I want to make sure we come out of this F2F comfortable with shipping what we've resolved on. Does anyone have a list of open issues for beforeInput?

Anything else we should try to discuss?