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

Google has confirmed that they can host this meeting - logistics to come  

I've put up a meeting page with an agenda at  
(and linked from our WG meetings page

Please add your name via Pull Request if you plan to attend, or let me  
know and I will add it for you.

Ditto for further agenda proposals.



On Mon, 09 May 2016 18:19:27 +0100, Chaals McCathie Nevile  
<> wrote:

> 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  
> <> 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]
>> [2]
>> [3]
>> [4]

Charles McCathie Nevile - web standards - CTO Office, Yandex - - - Find more at

Received on Sunday, 15 May 2016 07:43:05 UTC