- From: Grisha Lyukshin <glyuk@microsoft.com>
- Date: Wed, 27 Jul 2016 17:46:39 +0000
- To: Johannes Wilm <johannes@fiduswriter.org>, Dave Tapuska <dtapuska@chromium.org>
- CC: Ojan Vafai <ojan@google.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
- Message-ID: <BY2PR03MB160A7B88E04DAE44859E160AD0F0@BY2PR03MB160.namprd03.prod.outlook.com>
I've added the last mentioned item to the agenda list. Could you please add the other two? - Grisha Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: johanneswilm@gmail.com <johanneswilm@gmail.com> on behalf of Johannes Wilm <johannes@fiduswriter.org> Sent: Tuesday, July 26, 2016 5:48:27 PM To: Dave Tapuska Cc: Grisha Lyukshin; Ojan Vafai; public-editing-tf@w3.org Subject: Re: topics for Fridays F2F One more thing: As requested by the meeting of the browser makers, we have added a dataTransfer object to hold data about content that is to be added that is more than just simple text input. This can be obtained using: event.transferData.getData('text/html') A version of the same data converted to plain text can be obtained using: event.transferData.getData('text/plain') Now the question is, what should the relation between the plain text version and the value of event.databe. There is currently only one inputtype of the beforeinput event for which the data attribute is used (insertText). Would it simpliufy things if we: A) Use the dataTransfer object for all inputtypes where content data is involved and additionally thedata attribute for the insertText inputtype? (current option) B) Use the dataTransfer object for all inputtypes where content data is involved and not use the dataattribute at all? C) Use the dataTransfer object for all inputtypes where content data is involved except the insertTextinputtype for which we use the data attribute? https://github.com/w3c/editing/issues/131 On Wed, Jul 27, 2016 at 2:18 AM, Johannes Wilm <johannes@fiduswriter.org<mailto:johannes@fiduswriter.org>> wrote: I would also like to discuss this at some point: https://github.com/ProseMirror/prosemirror/issues/330 It seems to be something similar to IME input on Mac OS X for accents on European languages. The issue seems to be that it doesn't quite behave like other IME input in that there is first just a normal keypress event. It is only when the user doesn't let go of the key that a context menu with the different accent options is shown and that it becomes clear that this is actually part of a character composition. I just want to make sure that there is a better way for JavaScript to handle this when we move from listening to keypress to beforeinput events for text input. But I am Ok with waiting to deal with this to the meeting at TPAC. On Tue, Jul 26, 2016 at 11:04 PM, Dave Tapuska <dtapuska@chromium.org<mailto:dtapuska@chromium.org>> wrote: Also topics that are important to me are below. I don't know if anyone has an opinion on these. Standardizing: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-mozactionhint And specifying some modified type of inputmode (but it doesn't map great to android virtual keyboards; see https://developer.android.com/reference/android/text/InputType.html) for contenteditable. dave. On Tue, Jul 26, 2016 at 1:29 PM, Grisha Lyukshin <glyuk@microsoft.com<mailto:glyuk@microsoft.com>> wrote: This is the current agenda is below. Also available here<https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/16-07-29-Editing.md>. Dragging and dropping What should the order of the events be and in what spec should this be placed? Clipboard events Should paste and cut have beforeInput events? If so, should these be cancelable? Only in cE=events or also in cE=true? Should copy also have a beforeInput event? What if there is no editing host involved? 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? 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? static ranges A < href="https://github.com/w3c/editing/issues/104">non-finalized<https://github.com/w3c/editing/issues/104%22%3Enon-finalized> proposal was made at the browser meeting in January, and there is FrozenArray<https://github.com/w3c/editing/issues/104> (?) 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. 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 works for everyone * JS editor developers have asked for a way to be able to disable context menus (especially on mobile). * 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. * It was proposed<https://github.com/w3c/editing/issues/93> 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 * Which spec should this go into? (input events being one option) Relation to execCommand Does it really make sense to try to cover all execCommand commands with beforeInput types<https://github.com/w3c/editing/issues/79>? How about "copy" which doesn't change the DOM, or commands such as "insertImage" or "foreColor" which will recreate custom UI anyway? Publishing It would be good to get First Public Working Drafts of the things we are working on Sent from Outlook<http://aka.ms/weboutlook> ________________________________ From: Ojan Vafai <ojan@google.com<mailto:ojan@google.com>> Sent: Tuesday, July 26, 2016 11:38:33 AM To: public-editing-tf@w3.org<mailto:public-editing-tf@w3.org> Subject: topics for Fridays F2F Is anyone putting together an agenda? At the top of my list is resolving any open issues with beforeInput. I'd like to ship that soon in Chrome (e.g. in the next month or two), so I want to make sure we come out of this F2F comfortable with shipping what we've resolved on. Does anyone have a list of open issues for beforeInput? Anything else we should try to discuss? -- Johannes Wilm Fidus Writer http://www.fiduswriter.org<http://www.fiduswriter.org/> -- Johannes Wilm Fidus Writer http://www.fiduswriter.org<http://www.fiduswriter.org/>
Received on Wednesday, 27 July 2016 17:47:13 UTC