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

I have now linked to your proposal in the Input events spec:
http://w3c.github.io/editing/input-events.html

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

> On Tue, Apr 26, 2016 at 4:08 PM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
>>
>>
>> On Tue, Apr 26, 2016 at 6:30 PM, Gary Kačmarčík (Кошмарчик) <
>> garykac@google.com> wrote:
>>
>>> On Tue, Apr 26, 2016 at 3:08 PM, Johannes Wilm <johannes@fiduswriter.org
>>> > wrote:
>>>
>>>> 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.
>>>>
>>>
>>> Yes, that scenario sounds like it would be just as easy using a
>>> StaticRange or a Range, so (IIUC) that shouldn't be affected by this
>>> proposal.
>>>
>>
>> Indeed. I just mention that, because when I as a JavaScript developer
>> think of a range description being "static", I would expect it to have a
>> static description of both the offset and the node rather than link to a
>> node which continues to change and which may even be removed from the
>> document altogether.
>>
>
> Ah. That's a good point. We should call out that it's a "shallow" copy of
> the range. Do you have suggestions for a better term than "Static"? We were
> unable to come up with anything better.
>
> Also, can you reply with these comments in the WICG group? Positive
> responses there will speed it along the standard track.
>
>
>> The reason I ask is that if we want to move ahead with the input events
>> spec to FPWD and there are browsers looking at implementing it, it would
>> seem to be a good idea to link to a spec (draft) describing static ranges
>> being maintained somewhere. Else we may end up with beforeInput events
>> being implemented with slightly different static range functionality, and
>> we are back to where we are now.
>>
>> But maybe a description document like the one you published in the WICG
>> can work just as well for that purpose?
>>
>
> I believe that linking to the current WICG doc would work for that. Also,
> it you point out that the Editing spec needs to refer to it, it will
> probably be promoted to a proper spec faster that it would without that
> support.
>
>


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