page level onclick - can I detect nearest word
p7er...@gmail.com
I want to install a page level onclick handler that gives me the
nearest displayed word that the mouse was clicked. Is this possible?
Andy
Thomas 'PointedEars' Lahn
> I want to install a page level onclick handler that gives me the
> nearest displayed word that the mouse was clicked. Is this possible?
Unlikely. I presume it is at least not possible in every runtime environment.
PointedEars
p7er...@gmail.com
wrote:
Can I get the x,y position of the click and walk the DOM to see the
paragraph that contains it, and then approximately infer the word?
Jeremy J Starcher
> Can I get the x,y position of the click and walk the DOM to see the
> paragraph that contains it, and then approximately infer the word?
Perhaps if you explained what you are trying to accomplish?
Knowing your goal might help come up with a better route.
p7er...@gmail.com
I'm trying to insert annotations in a page onclick that are tied to
the word clicked. Will store the annotation in a DB with AJAX.
Andy
Jeremy J Starcher
There is an approach you can look at, but it is fairly fugly.
Wrap each word in its own span element, and use event delegation on the
paragraph to see which word was clicked.
For an example of event delegation, see
< http://cherny.com/webdev/70/javascript-event-delegation-and-event-
hanlders >
(Sorry if it wrapped. Yes, the last word is mis-spelled.)
For bandwidth reasons, I would wrap each word in a span tag on the client
side and for performance reasons I could NOT recommend this for long
blocks of text. I would either build a white-list of words to give
annotate, or I'd build a black-list of words that should NOT be annotated
(common words and perhaps any short words.)
We did something similar when working on a translation system.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn
wrote:
> > p7ere...@gmail.com wrote:
> > > I want to install a page level onclick handler that gives me the
> > > nearest displayed word that the mouse was clicked. Is this
> > > possible?
> >
> > Unlikely. I presume it is at least not possible in every runtime
> > environment.
> >
Please trim your quotes to the relevant minimum, don't quote signatures.
And get a real name.
> Can I get the x,y position of the click and walk the DOM to see the
> paragraph that contains it,
Yes, theoretically. Practically, there are too many variables to
consider, including computed font size and zoom level.
But you don't have to _traverse_ the _document tree_ (the DOM is an API
specification) here because the ‘click’ event bubbles (in all known
DOMs), that is, it is propagated upwards in the document tree by
default. Therefore, a non-capturing event listener added to an ancestor
node of the event target can handle this event for all descendant
(element) nodes:
document.body.addEventListener(
"click",
function(e) {
var t = e.target;
console.log(t.nodeName + ": '" + t.textContent);
},
false);
This is the standards-compliant approach which should work in Gecko-,
WebKit-, and Opera-based browsers (start in console mode or enable
Firebug [Lite]). I recommend you search for "_addEventListener" and
"dhtml.addEventListener" from my dhtml.js in order to get an idea of how
a cross-browser solution could look like.
> and then approximately infer the word?
Unlikely. For that, Jeremy's suggestion is your best bet.
HTH
PointedEars
Thomas 'PointedEars' Lahn
> document.body.addEventListener(
> "click",
> function(e) {
> var t = e.target;
> console.log(t.nodeName + ": '" + t.textContent);
> },
> false);
>
Supplemental:
However, this dynamic aproach (some call that "Unobtrusive JavaScript",
misguidedly), is only ever needed if
A) you don't have access to the markup of the ‘body’ element
or
B) the event does not bubble in all (target) environments.
In all other cases, the following is recommended (and equally
standards-compliant except ‘event') and should suffice (assuming HTML
4.01):
<head>
...
<!-- may be located within the ‘body' element instead -->
<script type="text/javascript">
function bodyClick(e)
{
/* see above */
}
</script>
</head>
<body ... onclick="if (typeof event != 'undefined') bodyClick(event)">
...
</body>
PointedEars
Martin Honnen
> I want to install a page level onclick handler that gives me the
> nearest displayed word that the mouse was clicked. Is this possible?
Mozilla exposes properties named rangeParent and rangeOffest, here is an
example for that:
http://home.arcor.de/martin.honnen/javascript/2008/12/test2008122201.html
In that example the click event listener is only set up for a div but
you could of course do that for the body element or the document object
itself if needed.
And it is only an example showing how to use event.rangeParent and
event.rangeOffset, the algorithm for finding a word is far from perfect,
in particular if a word could be marked up by several elements e.g.
<b>f</b<i>oo</i>
then you would need to improve that algorithm to find the word a lot.
With IE you should be able to create a TextRange
http://msdn.microsoft.com/en-us/library/ms535872(VS.85).aspx#
and use moveToPoint() to position it where the user clicked, then you
should be able to expand that range with expand("word") to find a word.
--
Martin Honnen
http://JavaScript.FAQTs.com/
Martin Honnen
> With IE you should be able to create a TextRange
> http://msdn.microsoft.com/en-us/library/ms535872(VS.85).aspx#
> and use moveToPoint() to position it where the user clicked, then you
> should be able to expand that range with expand("word") to find a word.
Here is the previous example updated to work with Mozilla as well as IE:
http://home.arcor.de/martin.honnen/javascript/2009/04/test2009040501.html
Only the behaviour in Mozilla and IE is quite different as the
expand('word') in IE works quite different from what I tried to
implement for Mozilla. With Mozilla if you click white space between
words then no word is found while it seems that expand('word') expands
to the nearest word to the right or left from the white space. On the
other hand the expand('word') in IE works well with clicking inside of
'Kibo' in e.g.
<strong>Kibo</strong>logy
to find the word 'Kibology' while my attempt for Mozilla does not work
for such cases, as already pointed out you would need to improve the
algorithm a lot to cover such cases.
Jorge
Garrett Smith
> Thomas 'PointedEars' Lahn wrote:
>
>> document.body.addEventListener(
>> "click",
>> function(e) {
>> var t = e.target;
>> console.log(t.nodeName + ": '" + t.textContent);
>> },
>> false);
>>
>> This is the standards-compliant approach [...]
>
> Supplemental:
>
> However, this dynamic aproach (some call that "Unobtrusive JavaScript",
> misguidedly), is only ever needed if
[...]
Event handler content attributes are best avoided. The use results in
the creation of a function with an augmented scope chain.
The design of a program where the callback exists in one place
(implementation js) and the registration exists in a separate file
(markup) is tight coupling; one type of change can require changing both
files together.
> standards-compliant except ‘event') and should suffice (assuming HTML
> 4.01):
>
> <head>
> ...
> <!-- may be located within the ‘body' element instead -->
> <script type="text/javascript">
> function bodyClick(e)
> {
> /* see above */
> }
> </script>
> </head>
>
> <body ... onclick="if (typeof event != 'undefined') bodyClick(event)">
> ...
Don't do that.
Using onclick in the body element will have different results in
different browsers. This fact was discussed here in recent months.
Give the example a doctype (to trigger standards mode), and a border on
body, and a simple statement inside the bodyClick function:
function bodyClick(e) {
alert(this + ", " + (e.target||e.srcElement));
}
The event handler gets mapped either to the window or to the body
element, depending on the browser and version (and doctype). The
attribute behavior is ambiguous. When the browser sees the event handler
attribute, it must create a function for either window or body. If the
browswer has an event for window, the window gets the event. For
example, all browsers have an onload for window and few have one for the
body element. SOme browsers have an onclick for window and an onclick
for body. Most browsers have an onfocus for window and many of those may
have an onfocus for body element (not to be confused with the body tag).
Garret
John G Harris
wrote:
<snip>
>Event handler content attributes are best avoided. The use results in
>the creation of a function with an augmented scope chain.
>
>The design of a program where the callback exists in one place
>(implementation js) and the registration exists in a separate file
>(markup) is tight coupling; one type of change can require changing
>both files together.
<snip>
Surely the alternative to a handler attribute requires the HTML element
to have an ID attribute that is known to some javascript code somewhere.
The ID must never, ever change or be removed by mistake. If you remove
an element you have to check that the js code hasn't used that element.
That's even tighter, or at least dodgier, coupling.
John
--
John Harris
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
> > Thomas 'PointedEars' Lahn wrote:
> >
> >> document.body.addEventListener(
> >> "click",
> >> function(e) {
> >> var t = e.target;
> >> console.log(t.nodeName + ": '" + t.textContent);
> >> },
> >> false);
> >>
> >> This is the standards-compliant approach [...]
> >
> > Supplemental:
> >
> > However, this dynamic aproach (some call that "Unobtrusive
> > JavaScript",
> > misguidedly), is only ever needed if
>
> [...]
>
> Event handler content attributes are best avoided.
Nonsense. We've been over this.
> The use results in
> the creation of a function with an augmented scope chain.
Correct, but irrelevant since the necessity to consider that fact can be
avoided when using as few properties in the attribute value as possible,
like here. You have been told before.
> The design of a program where the callback exists in one place
> (implementation js) and the registration exists in a separate file
> (markup) is tight coupling; one type of change can require changing
> both
> files together.
Don't start that stupid "Unobtrusive JavaScript" routine again, it's not
going to work.
> > standards-compliant except ‘event') and should suffice (assuming
> > HTML
> > 4.01):
> >
> > <head>
> > ...
> > <!-- may be located within the ‘body' element instead -->
> > <script type="text/javascript">
> > function bodyClick(e)
> > {
> > /* see above */
> > }
> > </script>
> > </head>
> >
> > <body ... onclick="if (typeof event != 'undefined')
> > bodyClick(event)">
> > ...
>
> Don't do that.
Nonsense.
> Using onclick in the body element will have different results in
> different browsers.
It will have the same result in all browsers as long as ’this’ is not
used (like here).
> This fact was discussed here in recent months.
> Give the example a doctype (to trigger standards mode), and a border
> on
> body, and a simple statement inside the bodyClick function:
> function bodyClick(e) {
> alert(this + ", " + (e.target||e.srcElement));
> }
‘this' is not used in my example, and it is not necessary to solve the
OP's problem.
> The event handler gets mapped either to the window or to the body
> element, depending on the browser and version (and doctype). The
> attribute behavior is ambiguous. When the browser sees the event
> handler
> attribute, it must create a function for either window or body. If the
>
> browswer has an event for window, the window gets the event. For
> example, all browsers have an onload for window and few have one for
> the
> body element. SOme browsers have an onclick for window and an onclick
> for body. Most browsers have an onfocus for window and many of those
> may
> have an onfocus for body element (not to be confused with the body
> tag).
Entirely irrelevant here. And you are confused about the meaning of
‘this’ in functions called from event-handler attributes.
PointedEars
p7er...@gmail.com
> Entirely irrelevant here. And you are confused about the meaning of
> ‘this’ in functions called from event-handler attributes.
>
> PointedEars
Thomas, these postings have left me confused. I generate the HTML
from a database and have complete control over the content. Based on
what everyone seems to be saying, I have to wrap every single word
with a handler and or ID. Am I on the wrong track? By the way, I am
a relative Javascript newbie even though I've read the book twice.
Andy
p7er...@gmail.com
> Entirely irrelevant here. And you are confused about the meaning of
> ‘this’ in functions called from event-handler attributes.
>
> PointedEars
Thomas, these postings have left me confused. I generate the HTML
Garrett Smith
Repost. apparently the previously sent message did not get sent, though
my "sent" folder indicates it was (and should have been posted after
2:06 PDT).
document.body works fine and does not require an ID attribute (and you
would not have to worry about removing that element, for obvious reasons).
Obviously, there is no tag for |window|. Something like onload, for
example, would be registerd on BODY and the browser would map the
callback to the window.
Some browsers support mouse events on window. Declaring a body onclick
attribute can result in the creation of an event handler callback on
either the window or the body element (the browser has to make a
decision). Some browsers might fire the callback from anywhere in the
window, others might only fire it from the body element. These some of
the inconsistencies.
You've argued that registering an event without using an handler
attribute requires the HTML element to have an ID attribute, creating
coupling. While the coupling of element id to script might be less
obvious, the argument is based on a false premise that an ID is
necessary to register an event. An element having an ID attribute is not
necessary and may not even be desirable in order to register events
(giving body an ID, for example, would not be necessary). It is
*impossible* to give the document itself an id attribute (no tag). By
registering mouse events on the document, the bubbled event can be
caputured there and the target/srcElement interrogated.
You've argued that if an element is removed, the developer must check to
see if the js has used that element. That is true, any change to a DOM
structure of a web application should be checked. Scripts can reference
many things that are directly related to that element: title, tagName,
className, parentNode, for example.
To me, changing that ID would seem to be a more intentional act than
changing some other parts of the HTML, such as adding a div somewhere.
If an author wants to signify meaning of an element, a meaningful ID can
convey that importance well to other humans (who might be reading that
source).
<span id="eventPickerActuator"
class="panelActuator">choose an event</span>
You have a point that the ID is an abstraction that is not tied to a
script, while an event handler attribute is tied to a script. In that
case, it would require investigation as to what other code (if any)
cared about that ID.
> John
Garrett
Thomas 'PointedEars' Lahn
p7er...@gmail.com wrote:
> [Thomas 'PointedEars' Lahn wrote:]
>> Entirely irrelevant here. And you are confused about the meaning of
>> ‘this’ in functions called from event-handler attributes.
>>
>> [...]
Thank you for trying to trim to what is relevant. But please include/leave
in an attribution line for each quotation level (because it's relevant).
Please don't quote signatures if you are not explicitly referring to their
content (because they are not relevant then). Please get a real name by
subscribing to the newsgroup (and updating your profile there), or
(recommended) by not using Google Groups for posting but a decent locally
installed newsreader application (e.g., Mozilla Thunderbird or KNode).
<http://jibbering.com/faq/#posting>
> Thomas, these postings have left me confused. I generate the HTML from a
> database and have complete control over the content. Based on what
> everyone seems to be saying, I have to wrap every single word with a
> handler and or ID. Am I on the wrong track?
I'm afraid so. Since you have "complete control over the content" and the
`click' event bubbles in all known DOMs, it is unwise of you to add the
listener dynamically (with the element type identifier or the element IDs as
point of reference), to pay (efficiency-wise) for necessary branching for
each `span' element, and to risk its not working properly despite all these
efforts (for several reasons discussed before).
Instead, you should use the event-handler attribute as in my example which
so far is known to work reliably and consistently among browsers/DOMs.
Simply try it out with a <span>word</span> to see how it works. (If you
can't get console.log() to work at first, use window.alert() instead.) Of
course, you need to test the `tagName' property case-insensitively, and you
may use the `class' attribute (and `className' property), so that you only
consider relevant `span' elements.
See also:
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow>
<http://www.w3.org/TR/2003/NOTE-DOM-Level-3-Events-20031107/events.html#Events-flow>
Please take notice that W3C DOM Level 3 Events is not a Recommendation yet,
but its event flow definition is much the same as in W3C DOM Level 2 Events
which is a REC, and the definition in L3 are easier to understand
(especially for beginners) because of the graphical representation.
These can quickly become complex issues, rather difficult to explain to a
beginner (because of all the technobabble that is needed). Nevertheless, I
shall try to set you on the right track so that the scripts you're going to
write are considerably better than what most of the wannabes on the Web and
in books produce nowadays. To that end, I do hope I could clarify, and not
add to, your confusion :)
(What I mean above is that Garrett is confused as to the meaning of `this'
within the called function in my supplemental, bodyClick(). Since that
function is not an event listener but only *called from* an event listener,
`this' within it refers refers to the Global Object [of which it is a
method] always. However, `this' within the event listener created by the
event-handler attribute value, `onclick', (which does not occur here there)
has different meaning depending on the browser/DOM because the `body'
element has a known peculiarity there.
If you don't understand what all that means, you may, but do not need to,
ignore it for the time being.)
> By the way, I am a relative Javascript newbie even though I've read the
> book twice.
Which book? Chances are you've read a bad book anyway.
PointedEars
Jorge
> (...) Based on
> what everyone seems to be saying, I have to wrap every single word
You ought to wrap each single word in a single htmlElement because the
target of a click event is an element.
If once you knew the target element you found it contained a hundred
words how would you tell apart the exact word then ?
OTOH, if you prepare the text in such a way that each target(able)
word is an individual element, then as the target element of the click
event contains the target word, you're done.
--
Jorge.
D.Campagna
> You ought to wrap each single word in a single htmlElement because the
> target of a click event is an element.
>
> If once you knew the target element you found it contained a hundred
> words how would you tell apart the exact word then ?
>
> OTOH, if you prepare the text in such a way that each target(able)
> word is an individual element, then as the target element of the click
> event contains the target word, you're done.
Thanks Jorge for your example (I downloaded it for future reference -
very interesting), I have followed the thread and was very curious on
how to accomplish the task.
D. Campagna
kangax
3 event listeners for each of 298 span elements? You can't be serious.
--
kangax
Jorge
No, just *one* global click event handler attached to document.body.
The onmouseover/onmousemove/onmouseout handlers aren't needed to
handle the clicks, I've put them there to highlight the words and
update the title in real time.
--
Jorge.
Jorge
OTOH, it would be perfectly ok to have 900 event handlers in a page...
why not ?
--
Jorge.
Jeremy J Starcher
>
> Here is the previous example updated to work with Mozilla as well as IE:
> http://home.arcor.de/martin.honnen/javascript/2009/04/
test2009040501.html
Fails under both Opera and Konqueror.
Jeremy J Starcher
This is close to the approach I was suggesting, but you should parse out
the text nodes and turn them into spans instead of building the page via
Javascript. That way, Javascript disabled browsers will get a limited
functionality instead of none-what-so-ever.
David Mark
> On Apr 6, 12:20 am, p7ere...@gmail.com wrote:
>
> > (...) Based on
> > what everyone seems to be saying, I have to wrap every single word
> > with a handler and or ID. (...)
>
> You ought to wrap each single word in a single htmlElement because the
> target of a click event is an element.
He ought to do nothing of the sort. Clicking text is like selecting
zero characters. As Martin mentioned, a proper solution involves text
ranges. Unfortunately, due to IE's proprietary implementation, a
cross-browser solution is difficult (though definitely not
impossible.)
Jorge
He does not want to *select* anything. He wants to know the word that
the user has clicked on. AFAIK, the best way to handle that with ease
is to wrap each word in an element. Either beforehand at the server
side or later on at the client side. If that's not a proper cross-
browser solution, please let me know why and what's the proper way.
--
Jorge.
David Mark
> On Apr 7, 1:50 am, David Mark <dmark.cins...@gmail.com> wrote:
>
>
>
> > On Apr 6, 9:46 am, Jorge <jo...@jorgechamorro.com> wrote:
>
> > > On Apr 6, 12:20 am, p7ere...@gmail.com wrote:
>
> > > > (...) Based on
> > > > what everyone seems to be saying, I have to wrap every single word
> > > > with a handler and or ID. (...)
>
> > > You ought to wrap each single word in a single htmlElement because the
> > > target of a click event is an element.
>
> > He ought to do nothing of the sort. Clicking text is like selecting
> > zero characters. As Martin mentioned, a proper solution involves text
> > ranges. Unfortunately, due to IE's proprietary implementation, a
> > cross-browser solution is difficult (though definitely not
> > impossible.)
>
> He does not want to *select* anything. He wants to know the word that
Who said he did?
> the user has clicked on. AFAIK, the best way to handle that with ease
Clicked.
> is to wrap each word in an element. Either beforehand at the server
> side or later on at the client side. If that's not a proper cross-
> browser solution, please let me know why and what's the proper way.
It isn't because it is a ludicrous end-around. And as mentioned twice
now, you use text ranges. If you had read my comment about clicking
text as something other than a brain-teaser, you would have a good
foundation to start.
RTFM, STFW, etc. It worked for me. :)
p7er...@gmail.com
> the user has clicked on. AFAIK, the best way to handle that with ease
> is to wrap each word in an element. Either beforehand at the server
> side or later on at the client side. If that's not a proper cross-
> browser solution, please let me know why and what's the proper way.
>
> --
> Jorge.
By the way, lets say that in editable page mode, I do indeed wrap each
word in an element. And the user selects a range of words and then
clicks. Will my event handler be able to detect each word in the
range as being a target of the click?
Andy
David Mark
> > He does not want to *select* anything. He wants to know the word that
> > the user has clicked on. AFAIK, the best way to handle that with ease
> > is to wrap each word in an element. Either beforehand at the server
> > side or later on at the client side. If that's not a proper cross-
> > browser solution, please let me know why and what's the proper way.
>
> > --
> > Jorge.
>
> By the way, lets say that in editable page mode, I do indeed wrap each
> word in an element.
That would be a very backwards thing to do.
> And the user selects a range of words and then
> clicks. Will my event handler be able to detect each word in the
> range as being a target of the click?
>
Not through any sort of help from extraneous elements. All they will
do is get in the way.
https://developer.mozilla.org/En/DOM/Selection
http://msdn.microsoft.com/en-us/library/ms535869(VS.85).aspx
Andy
> the user has clicked on. AFAIK, the best way to handle that with ease
> is to wrap each word in an element. Either beforehand at the server
> side or later on at the client side. If that's not a proper cross-
> browser solution, please let me know why and what's the proper way.
>
> --
> Jorge.
Jorge,
Can you suggest what I might do if the document that I'm munging
already contains a large <span> range? How can I wrap an individual
word then? Using <a>?
Andy
David Mark
Why are you asking somebody who doesn't have the solution for further
information about his non-solution? Doesn't seem like a strategy that
will bear fruit.
Andy
>
> Why are you asking somebody who doesn't have the solution for further
> information about his non-solution? Doesn't seem like a strategy that
> will bear fruit.
David,
Can you elaborate on the best solution. I checked your previous posts
and saw that you were talking about text ranges. But when you click a
text range, it disappears.
Andy
David Mark
They certainly do not disappear as they are not visible. You are
jumping the gun on those. See the links I posted (they point to
information on selections, not text ranges.)
Jorge
>
> Jorge,
>
> Can you suggest what I might do if the document that I'm munging
> already contains a large <span> range?
Can you post an example, or is it online somewhere ?
> How can I wrap an individual word then? Using <a> ?
No, just wrap them in more spans, nested <span>s are ok.
--
Jorge.
Jorge
>
> Why are you asking somebody who doesn't have the solution for further
> information about his non-solution? Doesn't seem like a strategy that
> will bear fruit.
We'll see.
--
Jorge.
David Mark
I don't care to see you re-enact some blunder from the days of IE3.
Why don't you ever listen?
Jorge
Why don't you post something for us to see (and learn) ?
--
Jorge.
David Mark
I did.