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



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