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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-dev
