Cross-Browser Mouse Event Handling

  • Thread starter Martin Rinehart
  • Start date
G

Garrett Smith

Richard said:
Garrett said:
Thomas said:
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.

Given a script "a.js" where a function |a| is defined inside it, and
then referenced in an event handler:

<script src="a.js"></script>

</head>
<body>
<p onclick="a()">...</p>

....

no problem, but if someone went and moved the script to the bottom,

</head>
<body>
<p onclick="a()">...</p>
...
<p>a lot of images, iframes, et c in this document...</p>
<script src="a.js"></script>

if the user clicks the p before a.js is loaded, the result would be an
error.
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

Bubbling ("delegation") could be done either way.
<snip>

That story gets put about as if it is some sort of universal panacea.

The decision to move the script to the bottom means that the html
elements reference the script via event handlers. The element appears
visually to the user before it is scripted. The interactivity that the
script would provide will appear soon after.
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.

Which browser does an external script block scrolling?

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.

I have seen network latency for 1x1 gif that took over 7 seconds to
load. This was a feature of an advertisement. It had the effect of
keeping the browsers progress bar from completing.

Reducing the file size matters, but will not prevent blocking. The
blocking includes the duration of latency.

Garrett
 
R

Richard Cornford

Thomas said:
kangax wrote: [...]
`handleClick` is not augmented, but the Function object whose
body is created from the value of attribute ("onclick" in this
case) is augmented with both - element in question and the
document (that this element is contained within) -
No, it isn't. The scope chain of the execution context is
different than when the function was executed elsewhere (you
could call that "augmented"), but that is to be expected.
And whether it is really a Function object that is called
remains to be seen; we are dealing with host objects here.

It isn't?

What is a function object in that case? Having a [[Call]] method makes
something callable (capable of being called by javascript) but it
would be possible to argue that a host object that is callable is not
necessarily a function object. Particularly if it could be shown to
have behaviour that was inconsistent with ECMAScript native function
object behaviour. Drawing such fine distinctions is more likely to be
argumentative than useful.
Then how can an example above be explained? It is also
written about on jibbering in "Unsafe Names" article [1] which
was, IIRC, reviewed and discussed here.

Not more than superficially. The account given of scope chain
augmentation barely touches the surface of the subject (asserting, as
it does, a single behaviour where many divergent behaviours have been
observed). See:-

<URL: http://groups.google.co.uk/group/comp.lang.javascript/browse_frm/thread/2d1bd03a4bc47add
- which includes some test code for examining what is really going on.
After reading it and then experimenting with few tests against
this behavior, I was pretty sure that's exactly what's
happening. Am I wrong?

Yes, but mostly in the sense that there is more going on that
described.

I understand that a person who knows what he/she is doing
will not likely run into these issues, but a beginner easily
might,

And a thousand others.
so I assumed that he/she would be better off using
object properties (if we are talking about these two options
only, and not about `addEventListener`/`attachEvent`).

Surly the best thing for a beginner is to become "a person who knows
what he/she is doing" and avoid the issues in that way? If someone's
browser scripting job can be done through nothing more than the blind
application of a set of rules then that person is ultimately
replaceable with software.


Was there a reason for not linking directly to the section on scope
chain augmentation, or does that resource not support such simple
hypertext concepts?

Richard.
 
R

Richard Cornford

Richard said:
Garrett said:
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.

Given a script "a.js" where a function |a| is defined inside
it, and then referenced in an event handler:

<script src="a.js"></script>

</head>
<body>
<p onclick="a()">...</p>

...

So the "the scripts" you referred to were external script files
imported by a web page rather than intrinsic event functions.
no problem, but if someone went and moved the script to the bottom,

</head>
<body>
<p onclick="a()">...</p>
...
<p>a lot of images, iframes, et c in this document...</p>
<script src="a.js"></script>

if the user clicks the p before a.js is loaded, the result
would be an error.

But a pretty much identical case follows when assigning to intrinsic
event properties. If you write - el.onclick = a; - and the code that
defines - a - has not yet been processed you get another error.

In the end there is an order in which things work and an order in
which they don't (or rather, many of each).
Bubbling ("delegation") could be done either way.

Yes, but there is no reason to expect that the function creation
overheads for a single intrinsic event attribute would be
significantly different form the function creation overheads for a
single function in any other context.
panacea.

The decision to move the script to the bottom means that the
html elements reference the script via event handlers. The
element appears visually to the user before it is scripted.
The interactivity that the script would provide will appear
soon after.

Or not that soon. And/or not necessarily before the user starts
attempting to interact with the element.
Which browser does an external script block scrolling?

Most of them have their UI blocked by javascript processing, which
includes the variable instantiation and global code evaluation
associated with loading an external resource.
I have seen network latency for 1x1 gif that took over 7
seconds to load. This was a feature of an advertisement.
It had the effect of keeping the browsers progress bar from
completing.

Reducing the file size matters, but will not prevent blocking.
The blocking includes the duration of latency.

So which browsers block the UI while HTTP requests are in progress?

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top