Re: Cross-Browser Mouse Event Handling

Garrett Smith wrote:
Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
kangax wrote:
Thomas 'PointedEars' Lahn wrote:
Martin Rinehart wrote:
But don't event handler attributes have their own problems
- notably a somewhat idiotic scope augmentation?

Wouldn't it be recommended to use something along these lines:
[snip]

The approach of assigning an event handler via script separates
the attachment from from the content, so the script can be moved
around to different place in the document.

And completely separating the function from the markup it is
operating on (and with) is a Good Thing, because ...?

"so the script can be moved around to different place in the
document"

That is not much of a justification. For a start it is not true; you can move the functions that are created from intrinsic event handlers around if you wanted to. After all, they should not be written to use their augmented scope chains as the augmentation itself is not guaranteed to happen at all, and is inconsistent between browsers where it does happen, and simultaneously that code should be written with the anticipation of the worst-case augmentation (where the element and all of its ancestors in the DOM hierarchy are added to the scope chain).

A better justification would being able to use the same code with many intrinsic events without suffering the overhead of creating many function objects. Though someone is likely to mention event delegation in response to that point.

<snip>
to allow the contents to render without being blocked by
one or more top scripts.
<snip>

That story gets put about as if it is some sort of universal panacea. When the contents that the reader is interested in are at the top of the document then putting them where they can be read as soon as possible might be a good ides. But it can be an irritating pain if what you are interested in is at the bottom of the page (such as the latest comments on a blog that you have already read) and the loading of the scripts at the bottom of the page block the ability to scroll. In that case I would rather not have the top of the page sitting there taunting me while the browser is not allowing me to scroll to what I am interested in.

It may be that the real issue is attempting to download too much script code, and playing around with where that code is loaded is just playing with the symptoms rather than addressing the cause.

Richard.

.

Relevant Pages

  • Re: "modern" javascript...
    ... Looking in the source to edit jspf, include, and tag files, or PHP ... As I said before, the event handler attribute ... True if the `script' element is the child of the `head' element. ... ISTM the example showed your idea of a "bottom script" quite well. ...
    (comp.lang.javascript)
  • Re: run another function after sorttable
    ... script was doomed from the start due to a thoughtless design. ... var _timer = setInterval{ ... // assign each event handler a unique ID ... Array.forEach = function(array, block, context) { ...
    (comp.lang.javascript)
  • Re: Cross-Browser Mouse Event Handling
    ... The approach of assigning an event handler via script separates ... Which browser does an external script block scrolling? ... Executing a script does freeze the UI, ...
    (comp.lang.javascript)
  • Re: "modern" javascript...
    ... HTML would only have one element ... event handler for the element's onchange event, ... the HTML, not in the js file, the script is more scattered. ... apparent value of "maintainability" etc. ...
    (comp.lang.javascript)
  • Re: Cross-Browser Mouse Event Handling
    ... But don't event handler attributes have their own problems ... the attachment from from the content, so the script can be moved ... imported by a web page rather than intrinsic event functions. ... Which browser does an external script block scrolling? ...
    (comp.lang.javascript)