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

[Ken Kocienda]

See my comments below. Thanks.

– Ken



On Apr 5, 2010, at 10:30 PM, Roland Steiner wrote:

> 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?


This is my fault. I made the initial error years ago to work with positions like [img, 0] - [img, 1] and [br,0] - [br, 1]. Though this is a mistake from the perspective of communicating positions outside of editing code, it is still very useful to know if a position is right before or after an image or br element. Some conveniences to ask such questions might be nice. 

If you wish to touch all the places in editing code where these degenerate positions are used, I have no reason to object.


> 
> 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).


For my part, layout tests check behavior, they don't define it. They are meant to prevent regressions due to mistakes and unintended consequences, not to prevent genuine behavior improvements.



> 
> .) 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.


Yes, there is much magic in HTML editing. I always found it very difficult to make simple rules and adhere to them due to the complications of handling all the corner cases. So, it's hard for me to comment on your simply-stated proposals, since the implications of such design changes are vast. It's not clear that such a refactoring would make the code easier to change or maintain, and that seems to be a much more important goal than implementing any single feature (e.g. non-contiguous ranges).

All that said, I am years removed from thinking about these problems on a regular basis. Mostly, I just wanted to own up to the position design mistake discussed at the top of the message. If only that were the greatest of my transgressions.


> 
> 
> 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/9fc6921b/attachment.html>