Re: topics for Fridays F2F

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>
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
> 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>
> *Sent:* Tuesday, July 26, 2016 11:38:33 AM
> *To:* 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?
>