Re: propose an API to return Range in <textarea> etc. form control nodes (similar functionality as document.caretRangeFromPoint)

Hi Maciej:

Thanks for your quick reply.
Then, I have other questions:
1. Why we would like to differentiate whether the node is a 'document' node
or a 'control' node? Can such differentiation be achived by existing flags
in node instead of "offsetKind"?

2. If we expose the control node, how to deal with the concerns Olli raised?
"Do you really want to expose those (native) anonymous DOM nodes to
web? What should happen if one tries to append them to normal DOM?
Or removes them? Or adds (mutation) event listener to them?"
3. From user's point of view, I think we probably need to have a convenience
method for converting a Range, and it probably should not give null for a
control position. We would need both the node and the offset for further
processing.


Thanks,
Xiaomei


On Fri, Oct 16, 2009 at 10:39 AM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Oct 16, 2009, at 10:23 AM, Xiaomei Ji wrote:
>
> 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?
>
>
> The node for the <textarea> would be the one reported (or of the <input
> type="text"> or whatever kind of form control it was). The concepts of
> "shawdowAncestorNode" and shadows trees in general do not exist as far as
> Web standards are concerned. These things are implementation details of
> WebKit.
>
>  - Maciej
>
>
> Thanks,
> Xiaomei
>
>
> On Mon, Oct 12, 2009 at 1:50 PM, Maciej Stachowiak <mjs@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 <xji@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
>>
>>
>>
>
>