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

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

> On Tue, Jan 12, 2016 at 6:54 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>>
>> On Wed, Jan 13, 2016 at 3:01 AM, Grisha Lyukshin <glyuk@microsoft.com>
>> wrote:
>>
>>>
>>> These are the outcomes that attendees felt was the right course of
>>> action, please provide feedback on those.
>>>
>>> •     We should Keep beforeInput/input naming as per Sapporo meeting
>>> resolutions.
>>> •     beforeInput/input events should be fired for any element with
>>> contentEditable enabled, input and textArea elements where input element
>>> and textArea will have targetRanges set to null- *#96*
>>> <http://beforeInput/input%20events%20should%20be%20fired%20for%20any%20element%20with%20contentEditable%20enabled,%20input%20and%20textArea%20elements%20where%20input%20element%20and%20textArea%20will%20have%20targetRanges%20set%20to%20null.>
>>> •     We should rename EditTypes to InputTypes - *#97*
>>> <https://github.com/w3c/editing/issues/97>
>>>
>>>    -    We should remove EditTypes/InputTypes it from the UI events
>>>    spec.  It should be specced in editing Spec - *#98
>>>    <https://github.com/w3c/editing/issues/98>*
>>>
>>>
>>>
>>> •     Base definition and ordering of beforeInput/input events should be
>>> in UI events, but the editing specific stuff should be in a separate
>>> editing spec - *#99* <https://github.com/w3c/editing/issues/99>
>>> •     Cancelable attribute should be removed from the spec because it
>>> already referenced in Event.idl - *#100*
>>> <https://github.com/w3c/editing/issues/100>
>>>
>>
>> Ok, so a lot of this seems to be about moving large parts of the spec
>> into the UI events spec. Right now the division is:
>>
>> contentEditable: explains the three new contentEditable types (caret,
>> events, intentions) and points to contentEditable=True document for a
>> description of the existing stuff. Of the three new editing types we will
>> only describe one  in detail at this time and implement that one. But which
>> one that is changed about 3 times per week.
>>
>> inputEvents: Describes the beforeInput and Input events + has some
>> information about the order of events in relation to compositions.
>>
>
> Correct. This spec (which is an ED that has apparently never been
> published) was mostly extracted from UIEvents a year ago because at the
> time is seemed to make sense to do so. However, separating it out like this
> causes confusion WRT where the core event timing (event ordering) should be
> specified. Our desire is to have the event ordering for
> input/beforeinput/composition/keyup/keydown/... defined in one place
> because it can be tricky, and the only place it makes sense to do that is
> in UIEvents.
>
> UI events: mentions the order of beforeInput/Input in relation to other
>> events.
>>
>
> Also correct. And note that it's odd to define the event in one spec, but
> define the event ordering in another one. Which is why this division
> doesn't seem like a good idea anymore.
>
> Now if I understand you correctly, you would like to change this to:
>>
>> contentEditable spec: holds the list of events of the beforeInput/Input
>> event. Continues to describe the new type of contentEditable.
>>
>
> Not 100% sure what you're trying to say here with "list of events".
>





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


>
> UI events: holds everything else about the event.
>>
>
> More specifically, it holds all the core info about the event and how the
> event relates to other core ui events: composition, keyup/down, ...
>
> So, UIEvents would have something like:
>
> interface InputEvent : UIEvent {
>    readonly attribute data;  // since this is used by keyboard related
> events
>    readonly attribute isComposing;  // since UIEvents define the
> composition events
> }
>
> and the Editing spec(s) would have something like:
>
> partial interface InputEvent : UIEvent {
>    readonly attribute editType;
>    // dataTransfer - or whatever rich data format is used
>    // anything else that is editing related.
> }
>
> + all the other editing related stuff
>
> I personally don't mind how to do it, but I wonder if the only thing we
>> have of that event is the list of edit types, and we put it into a
>> "contentEditable" spec, but it really also applies to <input type=text> and
>> textarea, is that really making it less confusing? If we do move the event
>> into the UI events spec, then maybe we should move the entire thing,
>> including the list of edit operations there?
>>
>
> No, the list of edit operations is clearly editing related and belongs in
> the Editing spec(s) and owned by the Editing-TF.
>
>
Ok, gotcha.


> Else we end up with a spec that half-describes two different types of
>> contentEditable and one fully, and has a small part of the information
>> relevant for an event that is described in another spec and is relevant for
>> elements that aren't contetnEditable at all.
>>
>
>

> How the editing spec(s) are organized is separate issue. The important
> takeaway is that core event info that is not editing-specific shouldn't be
> in the editing spec. This means that the UIEvent spec (which provides core
> info) should not depend on the Editing spec (which provided higher-level
> structures), whereas the reverse is OK.
>
>
>> •     We should fire beforeInput event before compositioinupdate.
>>> Reasoning: IE/Edge fire compositionupdate after the DOM has been modified,
>>> Moz/Saf/Chrome fire it before the DOM has been modified - *#101*
>>> <https://github.com/w3c/editing/issues/101>
>>> •     Chrome/Safari need to fix a bug. Compositioinupdate is not firing
>>> before the compositionend - *#102*
>>> <https://github.com/w3c/editing/issues/102>
>>> •     isComposing field should be consistent with the composition
>>> events, no need to redefine it. So just provide a reference to spec -
>>> *#103* <https://github.com/w3c/editing/issues/103>
>>>
>>
>> Can you explain this a little more? What is the isComposing field to hold?
>>
>
> 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.


>
>
>> •     We should update the spec with an ImmutableStaticRange that is a
>>> subset of the Range interface and return them via the getTargetRanges
>>> method. s/ImmutableStaticRange/StaticRange/ in the actual spec - *#104*
>>> <https://github.com/w3c/editing/issues/104>
>>>
>>
>> If everything about the event has been moved to UI events except the lsit
>> of InputTypes, wouldn't this also be in the UI events spec?
>>
>
> No, because it's not related to the core UI events. It's only needed to
> get the current selection (ie: when editing).
>
>
>> •     We could have "data" property that returns the text/plain version
>>> and a dataTransfer field for richer things - *#105*
>>> <https://github.com/w3c/editing/issues/105>
>>> •     We should keep data in UI events for beforeInput that does the
>>> text/plain serialization. We should add dataTransfer to the editing spec
>>> for other mime types(html, text with line breaks, etc) - *#106*
>>> <https://github.com/w3c/editing/issues/106>
>>>
>>
>> This sounds like you will want to have another part of the event
>> described in the contentEditable spec, correct? Wouldn't it be confusing if
>> this data attribute is described in one spec if it's about "text/plain" and
>> in another if it's about line breaks? Could you also explain udner what
>> circumstances the data attribute is being used?
>>
>
> 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.


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


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

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