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

[Maciej Stachowiak]

On Apr 7, 2010, at 12:11 AM, Roland Steiner wrote:

>
> 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.
>
> The basic idea would mainly be to combine PositionIterator and  
> Position into one class "EditingPosition" (or just "Position"),  
> focusing on performance, and to move renderer-specific code into  
> VisualPosition (which could be (re-)named "RenderedPosition" for  
> clarity). Apart from an IMHO clearer code separation this should  
> also help improving the handling of :before/:after content  
> renderers, which currently is buggy.

It's not clear to me how "PositionIterator" is the same concept as  
"EditingPosition". The latter implies that it would only ever  
represent a position where you can edit. The former implies that it  
produces a sequence of positions (perhaps retaining additional state  
to be able to step forward/back efficiently). It also seems to me that  
it is useful to have a concept of a Position that is primarily  
optimized iteration.

I'm also still not clear on the proposed relation between  
EditingPosition and VisiblePosition. Does every EditingPosition have  
an associated VisiblePosition? How about vice versa? Is the mapping  
one-to-one?


>
> DOMPosition/RangeBoundaryPoint would continue to be just the bridge  
> to JavaScript code and not used in (most) editing code.
>
>
> 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.
>
> I don't understand: Safari and Chrome both do basically exactly that  
> (albeit in a somewhat souped-up fashion) - why is this capability  
> good in the browser, but not for user scripts?

Safari doesn't make this non-contiguous region a selection. It marks  
it with a visual highlight. Only the first hit is actually selected.  
This makes a big difference when doing a find in editable text -  
typing only overtypes the first hit, rather than replacing the non- 
contiguous selection.

Being able to represent a non-contiguous region is interesting, but it  
would be UI hell to allow such a thing to actually act as the user  
selection, and to get copied and pasted.


>
> On Wed, Apr 7, 2010 at 3:53 AM, Justin Garcia  
> <justin.garcia at apple.com> wrote:
>
> For example:
>
> <div><img style="display:block"><img style="display:block"></div>
>
> [img1, 1] and [img2, 0] are different visually but would both be  
> normalized to the same position under the above proposal.
>
> I think this is a great example and shows that normalizing [img, 0]  
> to [parent-of-img, index-of-img] can probably only happen once  
> styles and renderers are taken into account, which doesn't strictly  
> contradict Darin's point though (?).

I'm not sure how it implies that. Would you assign a real DOM position  
differently between the two styles?

I think the real difference here is in affinity, i.e. whether the  
caret would be at the end of one line or the start of the next.  
However this doesn't affect the DOM parent and offset.

Regardsm
Maciej



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