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