Re: topics for Fridays F2F

I have added the two issues I mentioned here on the list to the agenda list.

On Wed, Jul 27, 2016 at 7:46 PM, Grisha Lyukshin <glyuk@microsoft.com>
wrote:

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



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