[webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
mjs at apple.com
Wed Apr 7 00:36:47 PDT 2010
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
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
> DOMPosition/RangeBoundaryPoint would continue to be just the bridge
> 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-
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev