- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 30 May 2016 12:48:20 +0200
- To: Gary Kačmarčík (Кошмарчик) <garykac@google.com>
- Cc: public-editing-tf <public-editing-tf@w3.org>
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
Received on Monday, 30 May 2016 10:48:54 UTC