Re: "modern" javascript...

dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Peter Michaux wrote:
dhtml wrote:
Peter Michaux wrote: [...] Event handler attributes are fine for
small sites, but don't scale well.
That comes across as rhetoric. It depends how the site is set up.
Looking in the source to edit jspf, include, and tag files, or PHP
"helper" methods is more work than just editing the JS file. Long
event handler strings don't tend to be nicely indented like program
code should be. Instead, they usually get formatted like HTML
attributes.
That is a non sequitur.

Harder to debug one line.

OMG.

onclick="return handleClick(this)"

OK. So that leads to:-

handleClick(el) { func1(el); func2(el); }

Not necessarily.

Where func1 and func2 are unrelated in functionality, but grouped
together only by the fact that they need to be called by the same
element's event.

The mere fact that func1() and func2() can be used consecutively without
error marks a relation in their functionality.

All the event handlers are now in handleClick.

Please revise your vocabulary. handleClick(), func1() and func2() are _not_
event handlers.

How can I [un]register callbacks to the input?

s/\[un\]register/remove/
s/register/add/
s/callbacks/event listeners/

Add: using the usual methods. As I said before, the event handler attribute
value defines the primary event listener. There is no good reason why
secondary, third aso event listeners could not be added to the element, and
it fact it is possible.

Remove: using the data stored in an event registry object; its unregister
method can try reading the `onclick' property.

It becomes more difficult when the element has two handlers for two
different things (this is often true for something like
document.body, or for an element that has a tooltip and another
widget).
More difficult?

Look at the example above. All that try/catch is messier. That's the
point.

Straw man. No serious Web author would write such a piece of junk.

UX = "user experience" d/l = "download"

http://www.google.com/

Don't be ridiculous.

In an international newsgroup like this, one should be slow to use
English abbreviations except for registered technical terms

I suppose there is actually a term registry somewhere?

There is, for example, the Jargon File, and of course Wikipedia. While
using the latter for lookup of a single term can be difficult, for there are
often more than 5 explanations for the same term, and an article does not
need to exist in a poster's native language.

Rule of thumb: When in doubt, do not abbreviate or do explain your
abbreviations.

In teh following, the HTML img tag won't be rendered until f.js has
downloaded and parsed/interpreted. <script src="f.js"></script>
</head> <body> <img onclick="f()"> </body> The script f.js will block
the download of the document, including the img tag. d. With a bottom
script, the img will tag will not be blocked by the download of
f.js:-
What you call blocked -- for which sufficient proof is still to be
showed -- other people call delayed display of an item

It's a delayed display of the whole page.

Not necessarily.

Calling it delayed display of an item is misleading.

True if the `script' element is the child of the `head' element. But for
example for `script' elements handling the events of forms and form
controls, I like them to be near to what is handled instead; usually within
the `form' element, but when reviewing this, it should better be before it.

until it is ready for use. Users can appreciate that to a certain
degree, and if you do not mindlessly copy-paste a bunch of references
to large script libraries into your markup, it is not going to be a
problem.

Pages that require a lot of javascript will notice the delay,
particularly if there is latency (this can happen with a CDN). While very
small for most users, a rendering delay can be noticeable.

One could argue that there are no "pages requiring a lot of 'javascript'"
had the author designed with graceful degradation and code minimization (I
mean reducing the code to its essentials, not trimming whitespace) in mind.

<body> <img onclick="f()"> <script src="f.js"></script> </body> An
example can demonstrate the problem effectively:
http://stevesouders.com/examples/move-scripts.phpzip.com/
Ahh -- but! What if the user is clicking the image while *it* is still
loading?

Is 'it' html img tag or the binary data?

There is no "img tag".

I assume 'it' is the binary img data (not the img html).

Correct, but if it were the other one it would not make much of a difference.

There goes your user experience, being replaced by a user annoyance, an
error message.

What sort of error message? Can you show an example?

| ReferenceError: f is not defined.

(M$ JScript's error messages are of course more verbose and less helpful
than that. Like in that old helicopter joke ;-))

I cannot make out what you are trying to say.
Using a bottom script is an effective performance trick that can
enhance (not hurt) the UX.
You are mistaken.

Was there something wrong with the example?

ISTM the example showed your idea of a "bottom script" quite well. However,
your assessment of its capabilities is still wrong, as I have explained before.

That doesn't mean anything. Event handlers and bottom scripts can
be used separately or together.
yes, event handler attributes can be used with bottom scripts, but
not in the same way. Consider the bottom script example, if the user
clicks the button and f.js has not been parsed, then there will be a
ReferenceError "f is not defined".
But that still does not mean anything.

It means that an event handler that calls a function that exists in a
bottom script will throw an error if it is called before that bottom
script has loaded. event handler attributes + bottom script will result
in script error.

So X and Y together are bad, because Y is bad (as demonstrated by your
example). That does not mean anything for X alone. See?

Using bottom scripts has been shown to significantly decrease
page load time.
The page load time is the same. The order the content loads
changes. Bottom scripts can make the problem worse as the page is
visible to the user for a longer period of time before being
enlivened.
Bottom scripts have that feature.
They will have that feature, because all the content that is supposed
to be interactive must be rendered first, and can therefore be subject
to any user interaction that cannot be handled at this point.

The handling would be either: 1) a script error if the event handler
attribute was used. 2) no interaction if the event handler wasn't
attached.

That is not handling, that is playing Developer's Russian Roulette. IOW,
you are accepting the possibility of shooting yourself in the foot. So be
it, but do not expect others to do likewise or to be convinced to do so.

Script errors are less acceptable than being momentarily non-dynamic, but
the non-dynamic state is an important consideration. If, for example,
there is a degradable script and the user clicks before the event handler
is added, that would result in a capable browser getting a degraded
experience.

Sorry, I fail to see the advantage in forcing the user to load content that
cannot be used, although it could be used if loaded in the correct order.

You are not making much sense. Widgets *are* content, at least they
should be for any chance of having an accessible application.

I was thinking more of the main content of the page. This includes h1 and
first paragraphs, tables, et c. The user has to be able to see things
before he can decide to interact with them. Navigation can go at the
bottom, so screen readers won't read it. A tooltip or empty panel div
would go at the bottom.

The tooltip belongs to an element, so it belongs in its start tag or
content. What is an "empty panel div"? What would be its use?

It always adds complexity, by the mere fact that it needs to address
several different DOM APIs before the event to be handled even occurs.

Legacy events are attached in the same manner.

There is seldom a necessity for that, though.

That MSIE does not support DOM Events is a shame, though.

It does not support *W3C* DOM Events, and yes, M$ should be ashamed.

If javascript is not enabled, then the user would not be able to
use those widgets anyway.
That is not true if the widgets are designed to degrade properly.
For example, a drop down menu as a nested set of lists.
drag and drop in Webkit, on a mobile device, won't work so well.
Obviously you do not know what the term "accessibility" encompasses.

And?

And therefore you are not in a position to lecture others about it.

Besides, this was _not_ about drag and drop at all, but about a *drop
menu*.

The discussion is about "unobtrusive javascript". Peter mentioned about a
menu to make a point about graceful degradation.

So what? You missed the point, talking about drag and drop when it was not
meant.

What was meant instead was a drop(-down) menu that is better implemented as
a nested list with links (than as a `select' element). And one does not
need (or want) "Unobtrusive JavaScript" for that, except for the HTC
fallback for IE 6 and below.

The original post about an ebook.

So?

But I'll bite.

and?

And you can see my argument below. Don't play stupid.

Neither will any "onmouseover" as the iPhone or N80 has no "finger
motion detector" above it's touchscreen.
It does not need to.

I don't know the N80, but finger motion detection *on* the touchscreen
is already implemented on the iPhone.

There's no way to detect "onmouseover" on the iphone and there probably
won't be.

You are wrong, as I have explained. If fingertip/stylus graffiti works (and
I have seen the former working IRL), it is entirely possible to implement
"onmouseover" there. For both actions the same tests must be made; dropping
then requires only a container object to receive the dragged object, and I
am pretty sure that it would be supported because Cocoa Touch apps are
already developed this way (as can be seen in the Apple's WWDC 2008 Keynote
for the iPhone 3G: <http://www.apple.com/quicktime/qtv/wwdc08/>, time index
ca. 00:09:40 to 00:19:10).

Hence dragging could be implemented as: the fingertip moves a certain
amount of length units off the first recognized position. Dropping:
fingertip position is no longer recognized while the dragged object is
positioned over a target that can handle the action.

In the latest iPhone.

A lot of users have older iphone.

They would want to install the update to 2.0. And please don't say they
could not afford it.

Drag/drom would require at the very least, some sort of adapter function.

No, it would not.

But you have to find it first.

getElementById does a pretty good job.

No, it does not. You have trimmed the essential part of my statement: you
have to find the *offending* element first.

Capturing bubbled events and checking the target is another good strategy.

That is beside the point.

Usually you are not having an issue with the registering call, but what
it does, the listener. And without digging through the whole
application (that is, markup, scripts and stylesheets) you do not know
where to begin because it is not obvious what was done with which
element. Surely you can see that.

It is less obvious when there are handlers 1) in the html 2) added and
removed via a script

The same logical fallacy again.

Having the actual object before attaching any callback handler is
useful because you actually have it.
That is circular. "this" is the element in the handler. So when the
handler runs you "have it".
Yeah exactly, only if and when the handler runs. With event system
that takes astring like YAHOO.util.event.on, it is possible to waste
cycles and fail silently:- var renamed = "notExistAnymore";
YAHOO.util.event.on(renamed, "mousemove", fn); This results in silent
failure when there is no element with the id renamed.
You are not making sense.

Would you please leave the parts of statements in that are vital to their
meaning?

There is an event handler for an element.

So far, so good.

The event handler is attached by a library that polls the document for
the element by id.

The event *listener* is added like that.

The implementation code (page js) is refactored so that the element is no
longer in the page.

And that is good, because ...?

The remainder is the event handler, that is attached by a library that
polls silently.

A library that has to be investigated by the debugging person to know about
it. That is better than reading the plain HTML event handler attribute's
value and go from there, because ...?

YUI is such a library, and when it fails, it can lead to event handler
detritus. The event handler can still exist in the code and will do
nothing. It will fail to attach itself to anything (the element was
removed). It will poll for the element and fail and silently.

That is YUI's problem, not that of the concept of event handler attributes.

One could even argue that event handler attributes persisted for eight years
despite corresponding DOM event methods because they proved themselves as
being much more reliable. And seriously, when would there be a need to add
more than one event listener for the same event on the same object? Very
seldom, I presume.

Attaching an event to an object can fail fast and throw an error.

No doubt about that. If only you would see that therefore the "Unobtrusive
JavaScript" approach is doubtful at best.

Certainly it is more efficient to handle the event only when it occurs,

Only? How else? How could an event be handled when it does not occur?

My argument goes on below.

and prepare the necessary elements for that while parsing the
corresponding markup than to prepare all possible elements after
parsing for the possibility of the event that may never occur.

onload DOM traversal is generally slower than bubbling.

True. Your point in relation to my argument being?

Often it is the case where the page JS file (implementation code for a
page) will often register callbacks for the document events (mousedown,
et c). The callback checks the event target to see if it is something of
interest, and if it is, then call the constructor or factory method for
that widget and register events for other widgets. This needs an example
to explain...

I daresay it needs a dose of dope to be understood in the first place.

And then `this' provides a convenient, although only quasi-standard,
way to get the reference to the object handling the event (which as an
expression does not need to be feature-tested), and the equally
quasi-standard `event' to get the reference to the event object (which
as an expression should be feature-tested before use).

the thisArg for an event handler is the when it is attached as a property
assignment.

document.body.onclick = function(e) { alert(this.tagName); };

The same is almost always true for event handler attributes.

The "always", as I said, it equally doubtful. But it worksforme.

<body onclick="alert(this.tagName);">Time for dinner!</body>

Not using event handler attributes can require extra effort.

It does, there is no doubt about that. You are persistently ignoring the
"different DOM APIs" argument.

It does have some advantages.

Name one.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
.