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

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.


>
> @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.
>>
>
> One of the purposes (benefits!) of the WICG (
> https://www.w3.org/community/wicg/) is to get rough agreement before we
> need to decide where it needs to live.  Our hope is that all new proposals
> will start in the WICG incubator, stabilize a bit and then migrate to
> wherever the group decides it needs to be.
>
> Having said that, I think that it probably belongs in a separate spec,
> since it feels little odd to include it in Editing.
>


I think we agree on that.


> But thankfully I don't have to worry about that just yet. ^_^
>


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?



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