- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Tue, 31 May 2016 01:34:23 +0200
- To: "Dave Tapuska" <dtapuska@chromium.org>, "Ojan Vafai" <ojan@google.com>
- Cc: Gary Kačmarčík (Кошмарчик) <garykac@google.com>, public-editing-tf <public-editing-tf@w3.org>
On Tue, 31 May 2016 01:27:39 +0200, Ojan Vafai <ojan@google.com> wrote: > Seems to me like we should stick with the 29th. That's always the sensible default for a situation like this. :( cheers > On Mon, May 30, 2016 at 11:40 AM Dave Tapuska <dtapuska@chromium.org> > wrote: > >> 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 >>> >>> >> -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 30 May 2016 23:35:00 UTC