[webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes

[Roland Steiner]

On Wed, Apr 7, 2010 at 6:19 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> I'm not sure I understand that goal. It's pretty normal for an iterator
> type to be distinct from the type of thing it iterates over.
> vector<T>::iterator is not the same as T, even though it iterates over Ts.
> It is also not the same as vector<T> itself. I'm not familiar with the exact
> state of the editing code, but that's what I think of when I hear a
> suggestion to combine PositionIterator and Position.
>
> I'm also not clear on where the name Editing comes from. What is it about
> this kind of position that's related to editing? Is it only allowed to
> represent positions where editing can happen? If so, then it can't be a full
> replacement for either Position or PositionIterator, since those are used to
> represent non-editable locations. If it can represent even non-editable
> locations, then I wonder how it differs from your proposed DOMPosition -
> would it be just the support for fast iteration?
>

Yes, "Editing" seems a poor choice of term, let's stay with "Position". I
guess my proposal (which is actually not all that radical, I think) boils
down to:

1.) remove explicit support for "virtual" positions from Position.

2.) PositionIterator seems to be very limited in usefulness and after step
1.) there doesn't seem to be a reason why Position itself couldn't be
optimized for iteration and fast access the same way as PositionIterator is,
removing the need for a separate PositionIterator class.

3.) If we do step 2.), then everything that requires an explicit (node,
offset) interface requires a separate class. This class already exists in
the form of RangeBoundaryPoint. RangeBoundaryPoint + those additional
methods are what I termed "DOMPosition". Ideally, creation of a DOMPosition
would only be needed at the start and end of an editing operation as input
and result for JS.

4.) Bundle all code from Position and VisualPosition that operates on
renderers in VisualPosition and move code from VisualPosition that doesn't
operate on renderers back into Position. The resulting VisualPosition class
is based on renderers rather than nodes. Re-factor editing code that queries
renderers to use VisualPosition objects instead. (perhaps naming the class
"RenderedPosition" or somesuch might be clearer).


Could a VisiblePosition have more than one associated EditingPosition?
>

Right now I can't think of a circumstance where that could be the case (it
would basically mean a given renderer is associated with more than one
node).



> I think to correctly iterate over positions where editing can happen, you
> need to be aware of rendering. For one thing, you want to skip stuff that is
> not rendered. Are you imagining that EditingPosition would be purely DOM
> based? Would EditingPosition or VisiblePosition be the type of object that
> represents a place where you can put the caret?
>
> I understand and sympathize with your attempt to clean up editing concepts,
> but I am not getting a sense of clean separation here.
>

^_^; Perhaps that's because my proposal is not ambitious enough (and
discussing these exact points was what I was hoping for with my initial
mails):

In the initial version at least I probably would want to change as little
code as possible: DOMPosition as the bridge to JS, Position continuing to be
used for most of the current editing/selection logic, VisualPosition as
helper class, the interface to the renderers, etc.

So I guess the answer to where to store the caret position would at first
(continue to) be that VisiblePosition is used to discern the place where to
put it, but Position is used to actually store it (if that makes sense).

However, as you point out, much of the editing logic requires information
from the renderers. Ideally this would mean changing most logic to work on
renderers via VisiblePosition over time, leaving Position just as somewhat
of a husk between DOMPosition and VisiblePosition. This would also allow us
to neatly iterate over, and select, generated content (the question being if
we could actually make use of that). However, with renderers getting
destroyed and rebuilt constantly I'm not sure how far this is feasible.


Cheers,

- Roland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100407/770d127a/attachment.html>