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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
