[webkit-dev] Proposal to Reorganize Position Classes

[Ryosuke Niwa]

On Wed, Feb 2, 2011 at 3:16 AM, Roland Steiner <rolandsteiner at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110202/1176a855/attachment.html>