(sorry for the spam, send last time using the wrong 'from' email address to the public mailing lists)
Hi Maciej: Thanks for your comments. I have a question about "interface CaretPosition": In case of form control node, such as <textarea>, the 'offset' is the character offset within the <textarea> under mouse, 'offsetKind' is "control", what is the value of 'containingNode"? Is it itself or its shadowAncestorNode? Thanks, Xiaomei On Mon, Oct 12, 2009 at 1:50 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Oct 12, 2009, at 1:08 AM, Anne van Kesteren wrote: > > On Fri, 09 Oct 2009 19:04:52 +0200, Xiaomei Ji <x...@chromium.org> wrote: >> >>> Maybe I should propose Document.wordFromPoint() which directly returns >>> the word under the mouse (and handles both the DOM node and non-DOM form >>> control nodes). >>> It hides the information about the node and should be a useful API. >>> >> >> Don't you need at least some context information as well besides just the >> word? Although I suppose you can get that using a combination of >> elementFromPoint and wordFromPoint... >> > > I think we should consider changing caretRangeFromPoint's return type, if > it's not too late. It's useful to get the caret position inside a text form > control, beyond the immediate use case. > > Instead of returning a Range, caretRangeFromPoint could return an object > like this: > > interface CaretPosition { > readonly attribute Node containingNode; > readonly attribute int offset; > readonly attribute DOMString offsetKind; // "document" or "control" > } > > It could have a convenience method for converting a Range too, if that's > really needed (which would give null or something for a control position). > > Regards, > Maciej > > >