Hi all,
*
*
*While I'm not intending to write a patch for the following proposal anytime
soon, I'd really like to get your feedback.*
*
*
As you might all know, Position classes in WebCore need refactoring and
cleanup. Part of it is due to legacy editing positions that do many
"magics", and we're currently in the process of removing them (see the bug
52099 <http://webkit.org/b/52099>). However, even if we didn't have legacy
editing positions, we still have rather clattered code base - there are many
global functions in visible_units.cpp and VisiblePosition is used all over
in WebCore/rendering - and reorganization of Position-related classes is
needed (see the bug 52098 <http://webkit.org/b/52098>).
I spent the last couple months to figure out what's the right solution and
realized that there are generally two use cases of VisiblePosition:
- To differentiate upstream/downstream to express caret positions
- To iterate through editable regions to implement editing commands
For the former use case, triggering layout or respecting editing boundary is
not needed at all, and the use of VisiblePosition seems an overkill. I
concluded that these two use cases should be addressed by two different
classes.
So I propose to implement the following 3 classes in lieu of the existing
Position and VisiblePosition:
- *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.
- *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.
- *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.
Now, I request for your comments!
Best regards,
Ryosuke Niwa
Software Engineer
Google Inc.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
