Re: topics for Fridays F2F

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>
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>
> 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?
>>
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org