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

[Maciej Stachowiak]

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?

Having fake positions like that is not good. I don't think there is a  
good reason for it. But the assumption got deeply embedded into the  
code, and it will take some doing to remove. One step in that  
direction would be to phase out all use of  
Position.deprecatedEditingOffset() and Position.node().

Another possible step in the right direction: make  
rangeCompliantEquivalent a direct method on VisiblePosition instead of  
a free function, and start phasing out use of  
VisiblePositon.deepEquivalent() in favor of  
VisiblePosition.rangeCompliantEquivalent(). Eventually the internal  
representation can be changed.

I am not sure offhand what other code uses the "deep" form of  
positions that may give positions at offset 0 or 1 from a void element.

Regards,
Maciej


>
>
> 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
>
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

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