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

[Roland Steiner]

On Wed, Apr 7, 2010 at 4:36 PM, Maciej Stachowiak <mjs at apple.com> wrote:

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

Perhaps "EditingPosition" is not the best of names. The basic idea is that
we shouldn't need 2 different classes Position and PositionIterator and
convert back-and-forth between them.


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

That is a good question - it depends how we want to treat stuff like
:before/:after content, list items, and such. A renderer-based
VisualPosition could technically select/iterate/identify such content, but
wouldn't necessarily have a corresponding Editing/DOMPosition. OTOH, an
EditingPosition probably would always have an associated VisiblePosition (At
least off the top of my head I can't think of a case where the user can edit
stuff that isn't rendered). An EditingPosition with reflection or somesuch
could in theory have more than one VisiblePosition, but I think that's
getting awfully fanciful.

However, the immediate idea here is more one of code separation: to put the
code that operates on renderers into its separate class.


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

FWIW Firefox seems to handle it fine, but I agree that it's probably not
used much in practice (apart from column selection as you mentioned). I'm
thinking more of feature-completeness vs. the HTML5 spec here, and the
aforementioned non-selection highlights.

But whether or not to add this should be a separate discussion.


>  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.
>
>
Yes, that's what I meant - the DOM Position itself should obviously not be
affected by styles/CSS. This however leads me to a clarification question of
my own:

The [img1, 1] in Justin's example would be an invalid position, no? Do you
mean that (the internal representation of) [img/block, 0] and [img/block, 1]
should render the caret at different positions (i.e., the start/left side
and end/right side of the block line, respectively)? Or did you mean the
case of 2 images (i.e., without a real internal visual position) on
different lines?


Thanks,

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