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

[Maciej Stachowiak]

On Apr 1, 2010, at 10:43 PM, Roland Steiner 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).

Which layout tests? Do they reference bugs? We can study the bugs to  
see if they truly ask for the behavior being tested.

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

Hard to comment on this idea from such a high level view. I don't  
understand how EditingPosition is meant to be different from  
VisiblePosition. Is EditingPosition just a VisiblePosition that's also  
a place where you can edit? I don't understand how DOMPosition is  
different in intent from the current Position. I'm not sure you want  
the low-level class to based on RangeBoundaryPoint, since the latter  
has the ability to adjust in response to DOM changes, which I am not  
totally sure we want in this case.

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

Non-contiguous selections suck as UI, except for special cases like  
selecting tables by column. I don't think they are a good way to  
highlight find results. I don't think you want to end up with a non- 
contiguous selection highlighting all results when you do a find.

Regards,
Maciej



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100405/7091bf0b/attachment.html>