Re: page level onclick - can I detect nearest word

John G Harris wrote:
On Sun, 5 Apr 2009 at 10:33:54, in comp.lang.javascript, Garrett Smith
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.


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
.

Relevant Pages