Meeting in California, July 29 Re: meeting in Berlin (late May or June)?

Hi folks,

we'll have a meeting in California Bay Area on July 29. I'll set up a  
meeting page later today, initially based on the following as a draft  
agenda.

We have an offer to try and host, but if anyone can definitely host (I  
don't expect more than a dozen people, and we need tea, coffee, and a way  
to eat lunch) please let us know.

cheers

Chaals

On Wed, 13 Apr 2016 23:44:58 +0100, Johannes Wilm <mail@johanneswilm.org>  
wrote:

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


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

Received on Monday, 9 May 2016 16:20:02 UTC