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

Nice!

Btw, I can understand how it makes sense from a browser perspective to use
static ranges and to only provide them when really needed.

Seen from a JS perspective, if I want to keep a record of the range or
share the with other clients (for example to communicate: "my user has just
selected this range, so please mark this range as being selected on all
other clients who who are currently editing the same document"), I will
likely want to store the offset together with a description of how to get
to the node in question (for example by describing a path to get to the
node starting from the editor-container at the time the static range was
first obtained) rather than the node itself. But this type of serialization
should not be too difficult to do in JS itself and the static range
proposal as it is should work fine with this.

@Gary: Where do you suggest for static ranges spec to live? If it's going
to be used all over the browser, included parts that aren't editing-related
(are they?), then maybe not among the editing specs themselves (?). At any
rate, we should link to it from the input spec.


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

> One of the proposals from this meeting was for StaticRange. I've written
> up an explainer for StaticRange and posted it on WICG Discourse:
> https://discourse.wicg.io/t/proposal-staticrange-to-be-used-instead-of-
> range-for-new-apis/1472
>
> On Wed, Jan 27, 2016 at 11:14 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>
>>
>>
>> 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
>>
>
>


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