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

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.