<div>Hi Maciej:</div><div><br></div>Thanks for your quick reply.<div><br></div><div>Then, I have other questions:</div><div>1. Why we would like to differentiate whether the node is a &#39;document&#39; node or a &#39;control&#39; node? Can such differentiation be achived by existing flags in node instead of &quot;offsetKind&quot;?</div>
<div><br></div><div>2. If we expose the control node, how to deal with the concerns Olli raised?</div><div>&quot;<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Do you really want to expose those (native) anonymous DOM nodes to</span></div>
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">web? What should happen if one tries to append them to normal DOM?<br>Or removes them? Or adds (mutation) event listener to them?&quot;</span><div>
<font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><span class="Apple-style-span" style="font-size: 13px; "></span><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">3. From user&#39;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.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"> </span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><div>Thanks,</div><div>Xiaomei</div><div> <br><br><div class="gmail_quote">On Fri, Oct 16, 2009 at 10:39 AM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Oct 16, 2009, at 10:23 AM, Xiaomei Ji wrote:</div><br>
<blockquote type="cite">Hi Maciej:<div><br></div><div>Thanks for your comments.</div><div><br></div><div>I have a question about &quot;interface CaretPosition&quot;:</div><div>In case of form control node, such as &lt;textarea&gt;,  the &#39;offset&#39; is the character offset within the &lt;textarea&gt; under mouse, &#39;offsetKind&#39; is &quot;control&quot;, what is the value of &#39;containingNode&quot;? Is it itself or its shadowAncestorNode?</div>
</blockquote><div><br></div></div><div>The node for the &lt;textarea&gt; would be the one reported (or of the &lt;input type=&quot;text&quot;&gt; or whatever kind of form control it was). The concepts of &quot;shawdowAncestorNode&quot; and shadows trees in general do not exist as far as Web standards are concerned. These things are implementation details of WebKit.</div>
<div><br></div><font color="#888888"><div> - Maciej</div></font><div class="im"><br><blockquote type="cite"> <div><br>Thanks,</div><div>Xiaomei</div><div><br></div><div><br><div class="gmail_quote">On Mon, Oct 12, 2009 at 1:50 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br>
 <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div><div><br> On Oct 12, 2009, at 1:08 AM, Anne van Kesteren wrote:<br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 On Fri, 09 Oct 2009 19:04:52 +0200, Xiaomei Ji &lt;<a href="mailto:xji@chromium.org" target="_blank">xji@chromium.org</a>&gt; wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 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).<br> It hides the information about the node and should be a useful API.<br>
 </blockquote> <br> Don&#39;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...<br> </blockquote> <br>
</div></div> I think we should consider changing caretRangeFromPoint&#39;s return type, if it&#39;s not too late. It&#39;s useful to get the caret position inside a text form control, beyond the immediate use case.<br> <br>
 Instead of returning a Range, caretRangeFromPoint could return an object like this:<br> <br> interface CaretPosition {<br>    readonly attribute Node containingNode;<br>    readonly attribute int offset;<br>    readonly attribute DOMString offsetKind; // &quot;document&quot; or &quot;control&quot;<br>
 }<br> <br> It could have a convenience method for converting a Range too, if that&#39;s really needed (which would give null or something for a control position).<br> <br> Regards,<br><font color="#888888"> Maciej<br> <br>
 <br> </font></blockquote></div><br></div></blockquote></div></div><br></div></blockquote></div><br></div></div>