Re: Outcomes from Informal Editing meeting on 7th Jan 2016

On Wed, Jan 27, 2016 at 7:43 AM, Johannes Wilm <johannes@fiduswriter.org>
wrote:

> On Tue, Jan 26, 2016 at 11:00 PM, Gary Kačmarčík (Кошмарчик) <
> garykac@google.com> wrote:
>
>>
>>
> From my perspective, I divide the content into "core UI event" (UIEvents)
>> and "editing" (Editing TF). In practice, the "editing" spec may be multiple
>> specs, but that's a detail for the EditingTF to resolve.
>>
>
> So altogether this sounds as if we are just moving some 2 attributes from
> the input-events spec to the UI-events spec - there has not been any
> protest about that, so let's just go ahead with that.
>
> As for structure of the editing documents:
>
> We keep 99% of the input events spec. And we will need to add more things
> related to dragging/dropping. Also, this is not just related to
> contenteditable, but also to textareas,etc. . And it is set to be
> implemented fairly soon.
>
> So probably it's best if we just keep that document as it is, apart from
> the future contenteditable document. Maybe the name should change if the
> core parts of the event are defined somewhere else, but we can figure that
> out along the way.
>

The "keep 99% of the input events spec" seems wrong to me.

I'm looking at: http://w3c.github.io/editing/input-events.html

(1) Introduction - no longer relevant since the events are introduced in
UIEvents. This would need to be updated to say that is contains additions
to these events to handle editing-related activities.

(2) Problem and Use Case. Only has a link to Editing Explainer document,
which doesn't actually talk about these events and only mentions
beforeinput in passing. This doesn't seem to add much value.

(3) Input Event Types.

(3.1) Interface InputEvent
|data| and |isComposing| are part of the core event in UIEvent
|inputType| stays with Editing
|cancelable| (which is spelled incorrectly in the spec) is already part of
Event and should not be duplicated here. Delete.
|targetRanges| no longer needed, but the replacement (the getRanges()
method or whatever) belongs in Editing

(3.1.1) Attributes
The info for |inputType| is the important part for editing. The rest are
either in UIEvents or deleted.

(3.1.2) Dictionary InputEventInit Members - goes into UIEvents since there
is nothing editing-related here

(3.2) Input Event Order - goes into UIEvents because it's part of the core
event description

(4) Input Events During Composition - goes back into UIEvents because it
describes order WRT other core events.

(5) Acknowledgements - Stay with editing. In any case, it's missing any
mention of the people who contributed to the UIEvents text (which is the
majority of the content in this spec).

Basically the stuff that was originally in UIEvents goes back into UIEvents.

If anything, it looks like 99% of the spec is going back into UIEvents.

isComposing is already part of some other events in UIEvents, where it is
>> defined relative to the compositionstart and compositionend events. The
>> definition of InputEvent.isComposing should be shared with the other
>> isComposing attributes (which is easier if they're in the same document).
>>
>
> ok, so we remove the text we have now about isComposing. Given that the
> isComposing is among the two fields that move to the UI events spec, we
> will not have anything about that in the editing tf maintained spec.
>

Correct. The editing spec does not need to define isComposing (although it
can refer to it).

InputEvent.data is used during keyboard events and thus it needs to be
>> declared in the UIEvents spec and defined for keyboard events.  The Editing
>> spec(s) can expand this description by providing additional info for how it
>> is used in editing contexts (eg: data contains the text/plain version while
>> the rich data is stored somewhere else).
>>
>
> Ok, let's try to see if we can get away with not saying anything in the
> editing tf document about the data attribute, just to keep the level of
> confusion down.
>

That's your call. I think it makes sense as container for the text/plain
data, but that's for the EditingTF to decide.


>
>>>>    -    We should  ensure drag/drop also fires beforeInput - *#107*
>>>>    <https://github.com/w3c/editing/issues/107>
>>>>
>>>>
>>> This would go into the UI events spec, right?
>>>
>>
>> No, because drag-n-drop are editing actions.
>>
>
> When I go to an image search engine and drag a JPG into the image drop
> area, that's not really about editing, would you say? Editing, as we have
> used the term here so far, has been mainly about textediting, specifically
> contenteditable and to a lesser degree input type=text and textarea.
>
> The UI events spec mentions dragging 7 times and dropping 4 times, but I
> can also see that the UI events spec is starting to get really full.
> Hmmm.....
>

We have to draw the line somewhere and key/mouse/IME have been spec'ed (to
varying degrees) for a while while contentEditable and drag an drop are
things that were added at a later date. That seems as reasonable a
definition of "core" vs "extra" as I can think of so that's where we have
the line drawn for now.

Note that keyboard events are also about text editing, but are much lower
level than the other stuff in the Editing spec. I think it's clear that we
don't want keyup/down to move into the Editing spec.


> Where the Editing spec(s) introduce drag/drop events, they would need to
>> specify the correct order relative to the core events (defined in
>> UIEvents).
>>
>
> How is this different from the beforeInput event related to keystrokes?
> Wouldn't the beforeInput event in case of drag/drop go into the list of
> events related to mouse clicking (or touch, etc.)?
>

Because beforeinput, keyup, keydown, composition* are core UI events and
form the minimal set of events that we need to have in the UIEvents spec.

Just because an event needs to be defined relative to the core UI events,
doesn't mean it has to be defined in the same spec as the core events.

Perhaps it makes sense for there to be a separate drag-n-drop spec.