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

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.

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.

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


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


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

>