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

[Roland Steiner]

One additional question on position classes:

The current implementation allows for (and operates on) positions such as
[img, 0] - [img, 1] or [br,0] - [br, 1]. Is there a fundamental reason to
keep such positions within the internal representation rather than normalize
them to [parent-of-img, index-of-img(+1)] - round-tripping perhaps?


Cheers,

- Roland

On Fri, Apr 2, 2010 at 2:43 PM, Roland Steiner <rolandsteiner at google.com>wrote:

> Hi all,
>
> As I am working on WebKit rich text editing these days, there are 2 issues
> that I would like to address. From a brief internal discussion both seem
> feasible and worthwhile, but since they involve changes to current code and
> behavior I wanted to ask the WebKit community in general, and the original
> authors of WebKit editing in particular, about your opinion:
>
> .) When a selection that starts in a table and ends outside it is deleted,
> the current code drags the adjacent outside content into the table. To me
> this is counter-intuitive (text can be "dragged" in, but not between cells,
> and not back outside), and it's also contrary to the behavior of other
> editors (FireFox, TextEdit, Word, etc.). The behavior is, however, enshrined
> in various layout tests, so I wonder if there was/is a reason to implement
> it this way. As this behavior also complicates fixing other bugs I wanted to
> see whether there would be much opposition to changing it (i.e., to content
> outside of a table staying outside on a delete operation).
>
> .) The current Position classes are IMHO rather unfocused in their
> implementation, with lots of special cases and "magical" behavior, that
> still is often incorrect (e.g., with text that has padding, margins, or
> :before/:after content). For ease of further development they would
> therefore benefit from refactoring. The idea would be to change the classes
> into something along the lines of:
>
>     DOMPosition: based on the current RangeBoundaryPoint, working on node +
> offset, interfacing with JavaScript
>     EditingPosition (or TypeablePosition): based on the
> current PositionIterator for fast iteration, with most of the code of
> Position except for code that queries renderers
>     VisiblePosition: change to work on renderers rather than nodes (moving
> such code from the current Position into this class).
>
> with explicit, but not implicit, conversion between them. Similarly for
> Ranges.
>
> In addition, a refactoring could add (or at least allow for) non-contiguous
> ranges and allow editing operations to work on arbitrary ranges/positions
> rather than just the (single) selection, which again currently is a pain
> point. In the long run I would envision to extend the code to allow multiple
> selections (such as for concurrent editing, or highlighting of find results,
> etc.), but that probably needs to be discussed separately.
>
>
> It would be great if you could share your thoughts,
>
>
> Cheers,
>
> - Roland
>
>
>
> *
> *
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100406/ab321fb8/attachment.html>