Re: Agenda proposal Re: meeting in Berlin (late May or June)?

On Thu, Apr 14, 2016 at 9:03 AM, Chaals McCathie Nevile <
chaals@yandex-team.ru> wrote:

> Cc+ Hallvord - not sure you're on editing-tf list
>
> On Thu, 14 Apr 2016 00:44:58 +0200, Johannes Wilm <mail@johanneswilm.org>
> wrote:
>
> Hey,
>> as I'm going through the remaining issues, it seems like there are still
>> a number of issues we need to deal with to get a good input events spec
>> up and running. The following are things I came across while going
>> through the issues on github. Maybe some of these things can be dealt
>> with quickly here, but there are likely other issues I haven't thought
>> about so far.
>>
>> What do people think? Would a meeting in Berlin in late May or June be of
>> interest?
>>
>> 1. Dragging and dropping:
>> -- What should the order of the events be and in what spec should this be
>> placed?
>>
>
> This is relevant to the HTML spec too, right?
>
>
Yes.

The situation is something like this:

We recently moved half of the beforeinput/input event into the UI events
spec, because the browser maker meeting in January thought it would be best
to have half of the events live there along with the order of events in
relation to keyboard input. The point being that placing it there
facilitate adoption.

But the UI events spec does not include order of events related to
dragging/dropping, which should also trigger beforeInput events, and the
spec is so large that the maintainers don't want to add it there either.

So this needs to go somewhere. The question is just where.

It seems to me that it would be the nicest if we could be as consistent as
possible on where we put things.


> cheers
>
> 2. Clipboard events:
>> -- Should paste and cut have beforeInput events?
>> -- If yes, should these be cancelable? Only in cE=events or also in
>> cE=true?
>> -- Should copy also have a beforeInput event? If yes, also if there is no
>> editing host involved?
>>
>> 3.  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?
>>
>> 4. 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?
>>
>> 5. static ranges
>> -- A non-finalized proposal has been made by the browser meeting in
>> January [1] and there is also FrozenArray (?) [2].
>> -- 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.
>>
>> 6. 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
>> work for everyone:
>> A. JS editor developers have asked for a way to be able to disable
>> context menus (especially on mobile).
>> B. 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.
>> C. It has been proposed 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 [3].
>> -- Which spec should this go into? (input events being one option)
>>
>> 7. Relation to execCommand
>> -- Does it really make sense to try to cover all execCommand commands
>> with beforeInput types [4]? How about "copy" which doesn't change the
>> DOM, or commands such as "insertImage" or "foreColor" which will
>> recreate custom UI anyway?
>>
>> [1] https://github.com/w3c/editing/issues/104
>> [2] https://github.com/w3c/editing/issues/113
>> [3] https://github.com/w3c/editing/issues/93
>> [4] https://github.com/w3c/editing/issues/79
>>
>>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
>  chaals@yandex-team.ru - - - Find more at http://yandex.com
>
>


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