[webkit-dev] Canonical positions

[Darin Adler]

On Nov 6, 2007, at 8:56 AM, Alexey Proskuryakov wrote:

> It looks like WebKit HTML editing code has several concepts of a  
> "canonical" position:

I can't answer the whole question, but I can give it a start.

> - Positions are not automatically canonicalized, but  
> Position.isCandidate() and PositionIterator.isCandidate() pick out  
> some of them as better ones.
>
> - VisiblePositions are automatically canonicalized with  
> VisiblePosition::canonicalPosition(). A Position that corresponds to  
> a VisiblePosition is called deepEquivalent.

A key concept here is that between any two visible elements, there are  
a number of different node/index pairs. For example, if you have two  
<img> elements in a row you could represent the position between them  
in two ways: 1) The parent of the image elements with a node index  
between them. 2) The second image element, with a node index of 0. As  
you include more types of content, there are more and more positions  
that are equivalent, but distinct. For example, if you have some  
content that is display: none, then a position anywhere within it is  
effectively equivalent to a position before or after the content.  
There are similar issues for collapsed whitespace.

What I don't know is exactly how those functions you mention above  
accomplish the task of efficiently figuring out the canonical position.

> - To be used in ranges, Positions have to be canonicalized with  
> rangeCompliantEquivalent(). Even VisiblePositions are not directly  
> suitable for use in ranges.

DOM ranges use a node and index to represent locations within a  
document. If the node is a text node, then the index is a character  
offset. If the node is not a text node, then the index is a child node  
offset.

But because of a historical mistake, much of the editing code uses a  
variant on this. In the editing version, you can have an <img> with no  
children (since image nodes can't heave children), but with an index  
of 1. This represents the position after the <img>. In a DOM range,  
that's just an illegal meaningless pair. The way DOM ranges express  
such a position is with the parent of the <img> and a node index set  
to the <img>'s node index plus one.

Having an alternate kind of node, index pair that can't be used with  
DOM ranges was a mistake in our editing implementation. But it's hard  
to remove that mistake from all the editing-related code.

In addition to the difficulty of keeping all the code working while  
changing the basic rules, it can be costly to compute a node index, so  
in some cases the (<img>,1) style is much more efficient to compute.  
So weaning the code entirely off these non-range-compliant node/index  
pairs is difficult.

     -- Darin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20071106/4a8bcc3b/attachment-0001.html