On Apr 6, 2010, at 9:29 AM, Alexey Proskuryakov wrote: > 05.04.2010, в 22:46, Maciej Stachowiak написал(а): > >>> 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? >> >> Having fake positions like that is not good. I don't think there is a good >> reason for it. But the assumption got deeply embedded into the code, and it >> will take some doing to remove. One step in that direction would be to phase >> out all use of Position.deprecatedEditingOffset() and Position.node(). > > I think that one reason is performance - "index-of-img" can be costly. But I > completely agree that we should try to get rid of these.
Let me elaborate on what Maciej and Alexey said. If we have an <img> element, there are three valid DOM positions adjacent to it: A: [ parent-of-<img>, child-offset-of-<img> ]: before the image B: [ <img>, 0 ]: inside the image C: [ parent-of-<img>, child-offset-of-<img> + 1 ]: after the image WebKit’s HTML editing code also makes use of an invalid DOM position: D: [ <img>, 1 ]: inside the image, but used to represent the position after the image Using D is never a good idea because it’s not a valid DOM position, so we can’t use it to construct a DOM range object. Having positions like D in our code at all leads to complexity and confusion. Using B to represent the position before the image is also unconventional; the position is clearly “inside the image element”, whatever that means. Given that, it seems that editing-related code that starts with a position such as B should quickly convert it to either A or C as appropriate. But computing A or C given a pointer to an image element is costly because it involves walking the parent's child nodes. In a large, flat document the cost is proportional to the size of the document. The same goes if we start with A or C and want to find the image element just before or just after the position. There are other issues when the document is being changed with positions extant. If we add a child element to the <img> element’s parent before the <img> element, both A and C end up pointing to a different place in the document, but B and D will still point where they did before. So if we convert editing code that currently uses a position like B to instead use a position like A, it’s easy to change behavior without realizing it. Encapsulating some of this into a class is one of the goals of the Position object, but we haven’t made much progress on untangling the mess. -- Darin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev