[webkit-dev] Proposal to Reorganize Position Classes

[Darin Adler]

On Feb 1, 2011, at 6:51 PM, Ryosuke Niwa wrote:

> 	• DOMPosition or SimplePosition - This class solely works on DOM, and is agnostic of renderers and other parts of WebCore.  It's meant to be used in utility functions and classes or passed along between renderers and WebCore/dom.  It doesn't know anything about upstream or downstream.

I’ve been hoping to turn the Position class into this for some time. I like to keep the “physics” (nodes, offsets, that sort of thing) separate from the “chemistry” (editing smarts, things that rely on rendering, style, and layout).

I don’t like the name “SimplePosition”. Maybe a good first step would be to rename the old class to DeprecatedPosition and this new class can be named Position.

Would this store a container node and offset using range-style technology, or would it have the features that the current Position class has that let it express positions before/after a node?

To me this just sounds like today’s Position minus all the high level functions that don’t belong as member functions.

> 	• RenderedPosition - This positions is an enhanced version of the current Position.  It represents every possible visible position and or DOM position and communicates vocabularies between WebCore/rendering and WebCore/editing.  It knows about line boundary and upstream/downstream but it doesn't trigger a layout, doesn't canonicalize, and doesn't know anything about editing boundary.  Its life-time is tied to layout cycle, and needs to be re-created every time DOM mutation or style change occurs. Many functions in visible_units.cpp can belong to this class as member functions.  Furthermore, PositionIterator could be merged into this class because RenderedPosition can cache pointers and other invariants as needed since RenderedPosition's lifetime is tied to layout cycle.  It can also share some code with TextIterator as well.

I don’t understand what state this would store besides the “DOMPosition” and thus I am unclear on why it’s a class rather than a set of functions. I do agree that this is an important category of functions that needs to exist. I can’t understand the proposal until you say more about what state this would store.

Your suggestion that we make the functions in visible_units.cpp into member functions doesn’t sound like an improvement to me. I would prefer a design that keeps the number of member functions small.

> 	• EditingPosition or VisiblePosition - This class is almost identical to the existing VisiblePosition. It knows everything DOMPosition and RenderedPosition knows, and respects editing boundary. A significant difference with VisiblePosition is that this class remembers the editable root element to which it belongs. So when crossing editing boundary, it can figure out whether or not we're still inside the same root editable root or not. It also knows how to canonicalize itself so editing commands can canonicalize positions as needed although canonicalization could be optional. I'm also not sure if this class should trigger a layout inside its constructor like VisiblePosition does or not yet.
> The introduction of RenderedPosition is particularly useful in rendering engine because it allows to express any caret/insertion point position with a guarantee that it doesn't trigger a layout.

Sounds OK to add a root editable element to VisiblePosition. Also seems fine to rename it. But I think there is more room for improvement in VisiblePosition than this, so I suspect this proposal does not go far enough.

Thanks for tackling this. I’m having trouble understanding your plans, so I’d like to hear more concrete details at some point.

    -- Darin