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

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.

@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. But thankfully I don't
have to worry about that just yet. ^_^