Selection.modify is really useful, but that you need to operate on the actual selection limits what you can reasonably do with it. We should expose the same API on Range. This helps with writing code that needs to navigation word or line boundaries (e.g. a custom spellchecker).
This seems to be a very useful feature and it's trivial to implement. All we need to do is to create a VisibleSelection out of a Range, and do modify operation on that VisibleSelection and get a Range object back.
(In reply to comment #1) > This seems to be a very useful feature and it's trivial to implement. All we need to do is to create a VisibleSelection out of a Range, and do modify operation on that VisibleSelection and get a Range object back. That's what I thought. But not really. For line and paragraph granularities, we have xPosForVerticalArrowNavigation. It's not clear at all what's the correct value to use if the selection is created out of a range.
This sounds like something that would go through standards bodies ideally.
(In reply to comment #3) > This sounds like something that would go through standards bodies ideally. I agree, but I think the DOM Range spec lacks an editor and is not being actively worked on. I did hear rumors of an attempt at a new version of the spec, but I don't remember seeing any updates. Ian, do you know?
I'm not sure if adding modify to Range is the right way to provide the said functionality. Exposing a new method on document / frame to create selection or make a clone of the selection might be a better idea because that'll allow developers to call any method provided by selection, and we don't need to add any exotic methods to Range. Usage 1: var selection = window.getSelection().copy(); selection.modify(...); ... window.setSelection(selection); Usage 2: var selection = window.createSelection(); selection.setBaseAndExtend(...); ... if (window.getSelection() == selection) doSomething();
If we could design this from scratch, I would not have a Range object at all. There would just be Selection and you could instantiate a Selection object that's not the browser's actual selection. Unfortunately, we can't start from scratch. So far we've taken the approach of trying to make Range and Selection more like each other, but maybe that's not the best way forward? You could imagine Selection being a subclass of Range.
(In reply to comment #6) > If we could design this from scratch, I would not have a Range object at all. There would just be Selection and you could instantiate a Selection object that's not the browser's actual selection. > > Unfortunately, we can't start from scratch. So far we've taken the approach of trying to make Range and Selection more like each other, but maybe that's not the best way forward? > > You could imagine Selection being a subclass of Range. The existing Selection and Range are nothing like each other, though. If selection was a subclass of range they would have some functions in common, but they don't. Who is the “we” here? Adding editing functions to the Range class sounds like a really bad idea. Having an object that can represent a range of text for editing seems good. We could start with a subset of the API of the selection object. Perhaps we can factor out a base class of the selection object, or just make an object with a similar enough API.
(In reply to comment #4) > I agree, but I think the DOM Range spec lacks an editor and is not being actively worked on. I did hear rumors of an attempt at a new version of the spec, but I don't remember seeing any updates. Ian, do you know? The current version of the spec is here: http://html5.org/specs/dom-range.html I'm actively working on it for the next few months, until the end of July or August. Last I heard it was supposed to be submitted to the W3C's WebApps WG, but I'm not sure what happened to that. Currently, the best place to send feedback or discuss improvements is the whatwg list: http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org (In reply to comment #7) > Who is the “we” here? Adding editing functions to the Range class sounds like a really bad idea. > > Having an object that can represent a range of text for editing seems good. We could start with a subset of the API of the selection object. Perhaps we can factor out a base class of the selection object, or just make an object with a similar enough API. I'm not sure what the difference should be between a regular range, and a range of text for editing. Note that per Gecko, IE, and the spec, unlike in WebKit and Opera, Selections are just containers for Ranges, and behave that way. In particular, any Range can be added to a Selection, even if it contains or consists entirely of invisible text, text in other documents, etc. From that perspective, putting features on Selection just makes them less useful than the same features on Range, unless they're like modify() and depend on Selection-specific things like direction (Selections can be backwards, Ranges cannot -- unfortunately). The whole API is admittedly a total mess, but it would be nice if we didn't add even more stuff to it unilaterally, because that will just make it more horrible. Starting with clear use-cases and discussing new features on spec lists before you start work on them would be a good idea, IMO.