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
node + offset, interfacing with JavaScript
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
