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

Hi,

it turns out that a Service Workers meeting was scheduled at the same time  
:( Is it possible for people to move this meeting to Friday 31 July?

cheers

On Sun, 15 May 2016 10:42:29 +0200, Chaals McCathie Nevile  
<chaals@yandex-team.ru> wrote:

> Google has confirmed that they can host this meeting - logistics to come  
> soon.
>
> I've put up a meeting page with an agenda at  
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-29-Editing.md  
> (and linked from our WG meetings page  
> https://github.com/w3c/WebPlatformWG/blob/gh-pages/Meetings.md
>
> 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.
>
> cheers
>
> Chaals
>
> On Mon, 09 May 2016 18:19:27 +0100, Chaals McCathie Nevile  
> <chaals@yandex-team.ru> 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  
>> <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 Friday, 27 May 2016 13:44:49 UTC