Given the following DOM and default CSS styling:
<div><span></span><textnode>foo</textnode></div>
I think it makes sense that getClientRects would return the same result for
the following ranges as they all correspond to the same visible position
(e.g. when a text input caret is there):
1. startNode: div, startOffset: 0
2. startNode: span, startOffset: 0
3. startNode: textnode, startOffset: 0
With the current spec 1 and 2 return the empty list and 3 returns a
zero-width rect. They should all return a zero-width rect with the same
values, which matches IE (in the cases where IE TextRanges can represent the
same Range).
The only use-case I can think of for getClientRects is to get the position
of the Selection for putting up context-specific menus. This makes the API
hard to use if code needs to first ensure that the endpoints are in
textnodes (e.g. in the empty span case, the code would need to first insert
a text node).
An alternative is to add getClientRects to the Selection object. That seems
a bit redundant to adding it to Ranges, but more importantly means that
calling code would need to modify the actual selection in order to get this
information.
Ojan