One additional question on position classes: The current implementation allows for (and operates on) positions such as [img, 0] - [img, 1] or [br,0] - [br, 1]. Is there a fundamental reason to keep such positions within the internal representation rather than normalize them to [parent-of-img, index-of-img(+1)] - round-tripping perhaps?
Cheers, - Roland On Fri, Apr 2, 2010 at 2:43 PM, Roland Steiner <rolandstei...@google.com>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). > > .) 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. > > 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. > > > It would be great if you could share your thoughts, > > > Cheers, > > - Roland > > > > * > * >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev