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

On Wed, Jan 27, 2016 at 6:55 PM, Gary Kačmarčík (Кошмарчик) <
garykac@google.com> wrote:

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

We still need an introduction so people know what they are looking at. Of
course we will point to the core part of the definition in the UI events
spec.


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

That was a document created by Ben. We will have to review that, but let's
keep that separate from this discussion.


>
> (3) Input Event Types.
>
> (3.1) Interface InputEvent
> |data| and |isComposing| are part of the core event in UIEvent
>

Yes, those are the two attributes we will move now.


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

Ok, so the remaining are: inputType, canceable, targetRanges  . For
targetRanges there is another ticket specifying that targetRanges will not
be available like that.


> (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.
>
>
Right, I had forgotten about 3.1.2/3.2/4. Of course these will go as well.


> (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).
>

We just started with the text as Ben provided it and didn't make much
historical research to determine whether other people had been involved.
Feel free to send a list of other people who should be mentioned here.


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

I don't think it makes much sense to quarrel about who gets the 99% as long
as we agree about what the changes are.


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

I agree with you that we shouldn't put more things into the UIevents spec
if that spec is getting to be too large. But let's not turn the editing
documents into a warehouse of leftovers that we didn't have anywhere else
to go either.

Is there nowhere else where the order of events related to dragging and
dropping could go?


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

Nono, in no way. I am just trying to look for consistency in what goes
where. We don't have the order of events related to keypresses that produce
beforeInput in the cE-TF spec. Nor do we have the order of events related
to mouse clicks. The order of the beforeInput related to mouseclicks should
probably be somewhere together with the eventslist related to mouseclicks.
That could either be the Ui events spec, or some other document.


>
>
>> 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.
>
> We agree that we have to draw the line somewhere and that the UI events
spec shouldn't hold everything that is remotely related to user input.


> Perhaps it makes sense for there to be a separate drag-n-drop spec.
>
> I think that could be one good solution.


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