[Webkit-unassigned] [Bug 34821] should add Range.modify to match Selection.modify

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=34821


Aryeh Gregor <Simetrical+webkit at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Simetrical+webkit at gmail.com




--- Comment #8 from Aryeh Gregor <Simetrical+webkit at gmail.com>  2011-03-27 10:50:35 PST ---
(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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.