IE provides an x,y, but FF and WK don't. I don't have a concrete proposal yet for what API to add here.
IE has getClientRects, getBoundingClientRect and boundingTop/Bottom/Left/Right on TextRanges. See http://msdn.microsoft.com/en-us/library/ms535872.aspx This mostly seems like the right API to me. I'd be fine with just adding getClientRects and getBoundingClientRect to Ranges. bounding* seem redundant with getBoundingClientRect. There's no reason to restrict this to Selections though. This ought to be possible on any Range.
Looks like this is already speced as part of CSSOM: http://www.w3.org/TR/cssom-view/#the-rangeview-interface Let's do it! :)
Actually, it doesn't help us. The getClientRects() method, when invoked, must return an empty (static) TextRectangleList object if the range is empty (if the boundary-points are identical) and otherwise a (static) TextRectangleList object based on the following conditions: That makes it impossible to find out where a collapsed range is! (i.e. the cursor). That's broken for our purposes, I guess I'll talk to Anne.
One answer to this would be to convince Anne to change CSSOM to make collapsed ranges return a non-empty rect. Another would be to add getClientRects and getBoundingClientRect to the Selection object. One question with either of those is what is the width of a cursor rect? Or the height? (line height?) And what about a split cursor on the mac? And are there non-text cursors we need to care about?
FYI the current workaround here @ Google is to insert a TextNode at the current caret and call getClientBoundingRect() on that inserted text node, and then remove it. :)
The other problem with getClientRects et al. is that they are not transform-capable.
To clarify, the workaround is to put in a span (can't get the position of a text node). This mostly works OK, but in addition to being a bit heavyweight, it has side-effects like changing wrapping behavior (putting a span in the middle of the word would make the word breakable at that point).
smfr can you think of an API we could expose that would be transform capable?
We can change the specification probably to still return a rect. I talked with Dean about transform capable APIs a while back, but it's not really my area of expertise. He said he would look into it.
(In reply to comment #4) > One answer to this would be to convince Anne to change CSSOM to make collapsed > ranges return a non-empty rect. I think this is the right direction. > One question with either of those is what is the width of a cursor rect? I'd return a rect of width 0. I think we want the invariant that for text on a single line, if you decompose a range R into a set of ranges (including empty ranges) that partition R, adding up their widths gives you the width of R. > Or the height? (line height?) The spec says for non-empty text selections, "the vertical dimension of each box is determined by the font ascent and descent"; maybe that's not precise enough, but the behaviour should be the same for empty and non-empty ranges. > And what about a split cursor on the mac? And are > there non-text cursors we need to care about? Determining the actual caret position and dimensions is a different problem. I'd actually prefer that we not expose that to Web apps unless you have a really good use-case for it --- I can't think of one myself, right now. (In reply to comment #7) > in addition to being a bit heavyweight, > it has side-effects like changing wrapping behavior (putting a span in the > middle of the word would make the word breakable at that point). A side issue, but IMHO that would be a bug in Webkit. Linebreaking is underspecified, but IMHO empty spans should not affect linebreaking and in Gecko they don't by design.
The spec was updated to work for collapsed ranges (and seems to be implemented in FF 3.7a). I'm going to close this bug in favor of the specific one implementing getClientRect for collapsed ranges (https://bugs.webkit.org/show_bug.cgi?id=34239)