On Wed, Feb 2, 2011 at 3:16 AM, Roland Steiner <rolandstei...@google.com>wrote:
> Just for context: Maciej and others had some feedback in the similar "Rich > Text Editing Questions, Refactoring of Position Class" thread from a year > ago (4/2/10). As an aside, I'm wondering if the general thoughts and > reservations about supporting positions inside :before/:after-generated > content and multiple ranges has changed in the meantime (?). > I don't think we're supporting multiple ranges anytime soon. But it should be orthogonal to this discussion because multiple ranges are tied to selection, not to positions. One of the motivations to do this refactoring was bugs related to first-letter. I think in the ideal world, we can isolate all code that deals with before, after, and first-letter inside RenderedPosition so that the rest of editing code doesn't need to know about them. >> - *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. >> >> How does RenderedPosition know line boundaries and upstream/downstream if > it doesn't trigger layout? > It assumes that the renderers are up-to-date. Just like you must be triggering layout before accessing renderer from nodes, you must trigger layout manually prior to creating a RenderedPosition. >> - *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. >> >> "A significant difference with VisiblePosition..." - do you mean vs. > RenderedPosition or vs. the current VisiblePosition? > With the existing current VisiblePosition. > >> >> 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. >> > > Not triggering layout is certainly a good point and something that should > bring quite a bit of performance. However, I wonder some of this > functionality shouldn't be factored out in a separate non-Position class > (say "SelectionManager"). > I don't quite get what you mean here. Could you elaborate? - Ryosuke
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
