Re: [Selection] Should selection.getRangeAt return a clone or a reference?

On Sat, Jan 24, 2015 at 9:52 PM, Olli Pettay <olli@pettay.fi> wrote:
>
> Right now the liveness doesn't really cause issues, since only some UAs
> support it.
> But that doesn't mean getRangeAt should return cloned ranges.
> Adding another getRange*At would just pollute the API.
>
> The more I think this, the more I'm leaning over to the option that we
> should play with
> live range objects with selection.
> (but perhaps there is some different kind of API model which
> can support multiple ranges and getRangeAt could be left as a legacy method
> and return clones.
> But adding something like getRangeProxyAt would not be such new model.)

The more you think of a nice feature, the nicer it looks to you. I
don't disagree with you.

Looks like we're in consensus that a) it doesn't really cause issues
today, and b) there are scenarios where live-ness is nice. The
difference is only that you think we should put in such thing now,
while I see such features can be added later and I'd like to spend our
time on other things.

If the current situation is not causing any practical issues, I'm even
fine not to define it in this level. Interoperability is important and
I like that, but if one particular difference does not trouble web
authors/developers at all, it can be left undefined, and we can
re-visit in Selection API Level 2.

>> In
>> selections and editing, we have so much we wish to do, I'd like us to
>> solve bigger issues first,
>
> Like what?

The Editing TF needs 4 more specs to be written, and the WG lacks
editor resources. As we discuss editing, there are some additional
requests to Selection APIs. These are that really cause issues today.

> How we end up supporting multiple ranges is rather big thing and something
> to keep in mind even if we end up having some kind of v1 spec without
> support for it.

Agreed. That's another concern actually. Making it live, with multiple
ranges kept in mind, would need more edits and thus need some time
from Ryosuke, the editor. I need his time spend more on
contentEditable=typing.

/koji

Received on Saturday, 24 January 2015 13:28:35 UTC