Bug 34821 - should add Range.modify to match Selection.modify
Summary: should add Range.modify to match Selection.modify
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-10 17:33 PST by Ojan Vafai
Modified: 2011-03-27 10:50 PDT (History)
14 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ojan Vafai 2010-02-10 17:33:25 PST
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).
Comment 1 Ryosuke Niwa 2010-12-04 14:58:58 PST
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.
Comment 2 Ryosuke Niwa 2010-12-04 17:40:57 PST
(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.
Comment 3 Alexey Proskuryakov 2010-12-05 00:56:58 PST
This sounds like something that would go through standards bodies ideally.
Comment 4 Ojan Vafai 2010-12-06 09:15:19 PST
(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?
Comment 5 Ryosuke Niwa 2010-12-06 09:31:17 PST
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();
Comment 6 Ojan Vafai 2010-12-06 10:56:14 PST
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.
Comment 7 Darin Adler 2010-12-06 16:28:02 PST
(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.
Comment 8 Aryeh Gregor 2011-03-27 10:50:35 PDT
(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.