On Sat, Jan 24, 2015 at 9:52 PM, Olli Pettay <o...@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