WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
34821
should add Range.modify to match Selection.modify
https://bugs.webkit.org/show_bug.cgi?id=34821
Summary
should add Range.modify to match Selection.modify
Ojan Vafai
Reported
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).
Attachments
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
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.
Ryosuke Niwa
Comment 2
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.
Alexey Proskuryakov
Comment 3
2010-12-05 00:56:58 PST
This sounds like something that would go through standards bodies ideally.
Ojan Vafai
Comment 4
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?
Ryosuke Niwa
Comment 5
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();
Ojan Vafai
Comment 6
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.
Darin Adler
Comment 7
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.
Aryeh Gregor
Comment 8
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.
Anne van Kesteren
Comment 9
2023-12-18 04:23:14 PST
Closing as per
comment 8
. We can reconsider once this is part of a standard.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug