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

That conflicts with my attendance to the pointer events hackaton at
Microsoft;
https://lists.w3.org/Archives/Public/public-pointer-events/2016AprJun/0170.html.
As previously indicated I was trying to get the editing and pointer events
in one west coast trip.

But again whatever works for the group is best.

dave.

On Mon, May 30, 2016 at 6:48 AM, Chaals McCathie Nevile <
chaals@yandex-team.ru> wrote:

> On Fri, 27 May 2016 19:27:50 +0200, Gary Kačmarčík (Кошмарчик) <
> garykac@google.com> wrote:
>
> 29 July 2016 is a Friday
>> 31 July 2016 is a Sunday
>>
>
> Yes. Now that I learned to read the months on a calendar, let me rephrase
> the request…
>
> Is it possible for those planning to attend, and for the hosts, to move
> the editing meeting to 26 July?
>
> cheers
>
>
> 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
>>>
>>>
>>>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>