[webkit-dev] Rich Text Editing Questions, Refactoring of Position Classes
mjs at apple.com
Mon Apr 5 22:51:34 PDT 2010
On Apr 1, 2010, at 10:43 PM, Roland Steiner 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).
Which layout tests? Do they reference bugs? We can study the bugs to
see if they truly ask for the behavior being tested.
> .) 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
> 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.
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.
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev