Agenda proposal Re: meeting in Berlin (late May or June)?

Cc+ Hallvord - not sure you're on editing-tf list

On Thu, 14 Apr 2016 00:44:58 +0200, Johannes Wilm <mail@johanneswilm.org>  
wrote:

> 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?

This is relevant to the HTML spec too, right?

cheers

> 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
>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Thursday, 14 April 2016 13:03:44 UTC