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

[Roland Steiner]

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/20100402/6648d093/attachment.html>