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

29 July 2016 is a Friday
31 July 2016 is a Sunday

On Fri, May 27, 2016 at 6:44 AM, Chaals McCathie Nevile <
chaals@yandex-team.ru> wrote:

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