Re: [webkit-dev] propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
(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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
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 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] 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 m...@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 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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
For a use case that pinpoint a word from a page, the context information needed besides word might be the language that the word is in.And yes, as you said, if the hit node is needed, elementFromPoint should do. Thanks, Xiaomei On Mon, Oct 12, 2009 at 1:08 AM, Anne van Kesteren ann...@opera.com 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... -- Anne van Kesteren http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
On Oct 12, 2009, at 9:37 AM, Xiaomei Ji wrote: For a use case that pinpoint a word from a page, the context information needed besides word might be the language that the word is in. And yes, as you said, if the hit node is needed, elementFromPoint should do. Hit testing isn't cheap - ideally we shouldn't design APIs that make you do it twice. - Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] propose an API to return Range in textarea etc. form control nodes (similar functionality as document.caretRangeFromPoint)
Hi Olli, Thanks for your comments. I see your point. 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. Thanks, Xiaomei On Thu, Oct 8, 2009 at 12:25 PM, Olli Pettay olli.pet...@helsinki.fiwrote: On 10/8/09 10:07 PM, Xiaomei Ji wrote: One use case is to show a tooltip of the word's definition in your accept-language when you mouse over the word in a page. It needs to 1. convert the mouse position to character offset within a node (by Document.caretRangeFromPoint() http://dev.w3.org/csswg/cssom-view/#the-documentview-interface), and 2. expand the range to 'word' unit. It is useful for users, especially users from east asian countries, to read the word's definition in their own language while browsing the internet. And it is also userful for users to check the word's definition in their own language while composing something, such as email. This is why I am thinking of displaying the word's definition for textarea. Which needs Document.caretRangeFromPoint() returns the textarea node as the range container node, and the offset as the character offset within textarea. But Document.caretRangeFromPoint() is only allowed to return nodes in the actual DOM, that a user would be able to get to by traversing from the root node. textarea node is not part of the DOM. Document.caretRangeFromPoint() cannot return a Range in a textarea since that Range would not be in the DOM. I would like to propose another API in Document which has the same functionality of Document.caretRangeFromPoint() but also works for textarea etc. form control nodes that are not part of the DOM. 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? I think we need a bit different kind of API for form controls. -Olli I do not have a good name in mind for such API yet. Would like to hear what you think. Any comments are appreciated! Thanks, Xiaomei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
